#MCUXpresso, LPC845, PEMicro Multilink Universal
I have been using a board for a couple of weeks now (our design) with no issues as I get all the hardware interfaces and state changes worked out before applying them to the application code. The last one is a loop going into powerdown mode with a wake-up using WKT, making an ADC measurement, printing it, rinse and repeat (file attached). Nothing too extreme, I thought. Unfortunately, when I ran it, the debug session crashed and, when I tried to restart it, the PEMicro Connection Assistant popped up saying there was an error when trying to make the connection. After this, I tried a previous program which had worked correctly and got the same result. Moving to different HW with the old program with the same PEMicro works. Trying the new program crashes the debug session and "bricks" the board. Trying a second known-working PEMicro also does not allow the connection. So, I now appear to have two boards to which I cannot connect, but no idea as to what I can possibly have done to affect them like this. Have I managed to blow something up? But how? The only line of code which I haven't used previously is 'POWER_EnterPowerDown(0U);'
Has anyone else seen something similar?
(BTW, both MCUXpresso and the PEMicro have the latest SW/FW versions)
Thanks.
Solved! Go to Solution.
Hello @malcolmmacdonald
It is possible to download an image into the flash on the target that will then prevent any further debug access or connections. The first thing to try to recover debug access is to boot into the ISP bootloader. This is normally controlled by the state of ISP pin(s) as the MCU comes out of reset.
About detail please refer to :
https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Regaining-debug-access-to-target-MCU/m-p/473923
BR
Alice
Thanks for getting back to me, Alice, but I don't understand your response. The SDK power_mode_switch_lpc example on the breakout board (OK, it's using the onboard debugger rather than the PEMicro) runs with no problems. I get that you can't use the debugger when it is in powerdown. However, that doesn't explain why I can't access the chip once it has executed this code. The problem stays with the board, so either something has been destroyed or something has been written to non-volatile memory.
Hello @malcolmmacdonald
"However, that doesn't explain why I can't access the chip once it has executed this code. "
->> Which code? power_mode_switch_lpc ? Or your own project?
You can enter ISP mode, use flash magic erase full chip, then debug again.
BR
Alice
As far as I can see (I have never used Flash Magic before) one can erase and reprogram all the program flash. How is that going to allow the Serial Wire Debug to work again?
Hello @malcolmmacdonald
It is possible to download an image into the flash on the target that will then prevent any further debug access or connections. The first thing to try to recover debug access is to boot into the ISP bootloader. This is normally controlled by the state of ISP pin(s) as the MCU comes out of reset.
About detail please refer to :
https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/Regaining-debug-access-to-target-MCU/m-p/473923
BR
Alice
OK, thank you, I am trying this. Unfortunately, the default FAIM programming is not the correct one for allowing external serial access - we were planning on setting that up at a later stage, but I suppose there is no time like the present! If this resolves the issue, it still leaves the question of exactly what in my code caused it to happen.