It didn’t help. And I haven’t changed the module yet, because I decided to focus on my own design for now. At some point, I’ll try to fix the development board.
Now, the debugger stopped working with another board (my design) that had been working before. This is the flakiest debugging/development environment I have ever worked with.
Whenever I set ENABLE_ACQUIRE to 1, the debugger apparently connects without any error message, but it doesn’t appear to do anything afterward. When I switch ENABLE_ACQUIRE back to 0 and try to connect, I get the same error message as before. So what is “acquiring” and what am I supposed to do after I have acquired the processor?
I’m sorry to hear that! PSoC6 is able to be acquired in two modes: testmode (ENABLE_ACQUIRE 1) and ‘normal’ mode. Testmode acquire is using accurate timing after reset and has to be set during a 1ms timing window. Normal mode acquire does connect the M4 core while running.
Now testmode acquire has the problem that the timing is often not accurate to acquire the M4. Normal mode has the problem that the M4 already runs and when the M4 runs into a fault state (or sleep) directly after starting, it can not be attached.
That’s why I advise the first instruction to be a CyDelay(1000); By doing this, there is at least a timeframe in which the M4 can be attached safely.
Your last working project, did it contain the CyDelay(1000) as the first instruction?
In the current project, a board of my own design, the first instruction in main() is (and was) CyDelay(1000). I have built two such boards so far. The debugger used to work on both, then suddenly quit working on the first one. This is the same behavior observed on my development board.
I was going to replace the module on the development board, but chose to focus on my own board instead. Now that one of my boards has also failed, I may go back to the development board. I should point out that, when powered, the development board appears to run the last program that was loaded, even though I can’t debug. However, I can’t be certain.
I am concerned that I might be damaging or somehow disabling the debug port, although I don’t see how that could be.
Do you use the red KitProg and if so, do you have a modification on the programmer for Vtarg to be set at 3V3?
The red KitProg should be used only with modification, otherwise SWDIO and SWDCLK will get too high (>3.6V). We never seen any problems with it however this might be the problem as I don’t can think of anything else.
At our github there’s the OTX upgrade phase 1, can you run this inside command prompt and show me the output?
Sorry, I see your screenshot. You obviously have the KitProg and the Vtarg set at 4.85V.
Please look at the upgrade I done for the Vtarg, just a simple solution to provide lower voltages to the chip.
The original Schottky diode D1 is removed
I placed two 1N4007 in series
It seems the voltage on SWD IO and SWD CLK will be set by measuring Vtarg. If Vtarg = 4.8V, the programmer will set the SWD lines to 4.8V which is too high.
Unfortunately, I did use a red KitProg without realizing that its output is fixed at 5V. I did use it with the development board and possibly with the 1st board of my design. I have since switched to a blue kitprog. I should probably order a Miniprog 4.
I will work with my second board and the blue kitprog. If the problem does not recur, I will consider the problem solved.
I replaced the module on the development board. The debugger worked - briefly.
I made the mistake of changing coreConfig.System.Idle.DebugOn to false, in order to see the effect on current consumption. Now I can’t debug, erase, or program the module. Changing the variable back to true and rebuilding doesn’t work, since I can’t debug anymore.
No that should not be the case. The idle mode will only occur when the M4 is waiting for the M0 to complete. Since you have a delay at startup, there still some time to acquire the M4 before it goes to idle.
Are you able to share your code so I can check on my end?
As soon as I delete the CyDelay at startup, I indeed bricked the module. This seems problematic, and I will try to find a way to ‘unbrick’ gain access to the M4 again.
I believe I had the CyDelay function present when I bricked my module. The action that seemed to cause problems was changing coreConfig.System.Idle.DebugOn to false.
I’m trying to understand the purpose of the CyDelay at startup. Apparently, it is necessary to keep the M4 busy for a while to allow debugging. Is this correct? If so, could I run other tasks instead during this interval?
Yes, when coreConfig.System.Idle.DebugOn is set to false, you are able to brick a module. This is what happens when the DebugOn is set to false:
Device resets, M0+ starts
M0+ enables the debug port
M4 starts
M4 initializes stack using LoRaWAN_Init(&coreConfig);
M0+ disables debug port
Now the time between 2. and 5. is very short if no delay is put at 3. (probably a few microseconds).
A few microseconds is not enough for the debugger to get attached to the chip. Therefor, adding a delay of 1 or 2 seconds before anything else wil allow a safe margine the debugger to access the chip.
This delay can be removed for a final version, which you don’t need to debug anymore. You can do other functions as long as the debug port isn’t disabled within 1 second from start.
I’m still checking with Cypress as I believe I am able to connect using the Testmode Acquire with the PSoCProgrammed CLI. I guess clearing the flash with the CLI can recover, I’m still waiting for Cypress to answer.
Thanks for the info. I’m starting to get a better understanding.
It is possible that I initialized the stack too early. In earlier testing I noticed that the power consumption decreased immediately after initializing the stack, so I moved the initialization up near the beginning of main(). I don’t think I put it before the CyDelay call, but I’m not certain (I need to take better notes).
I have more questions about minimizing power consumption, but I’ll start a new thread for that.
Sorry to hear that. Still working with Cypress to see if we can acquire in testmode in order to ‘unbrick’. I made some progress but still need the flash syscall code to erase the first flash row or sector.
Debugging quit working on yet another module. This time I am certain that CyDelay(1000) was the first instruction in main() and that debugging was enabled in both coreConfig and sleepConfig. Also, I used a blue (3.3V) KitProg3 exclusively. The module was powered by the KitProg. Here is the adapter output:
Can you tell more about the board you’re using? Do you use a custom board or our dev-kit?
I really want to get a grip on this and see what exactly happens. Also, are you able to send some of the bricked modules back so we’re able to investigate? You’ll receive new ones for the ones you’ll send.
