|
From: Andreas F. <and...@gm...> - 2017-09-25 14:48:25
|
On Mon, Sep 25, 2017 at 12:39 PM, Bohdan Tymkiv <boh...@gm...> wrote: > Hi Andreas, > > The main problem with PSoC6 devices is that CPU must be in Running state > in order to perform Flash Write/Erase operations. Normally this is done by > device boot code and is called TEST MODE. > > ... > Because we can not enter Test Mode, we have to find a safe way to execute > infinite loop in RAM. By saying "safe way" I mean that we have to find a > way to halt the CPU immediately after reset (prior to execution of user > code). And here comes problem #2: PSoC devices do not support Vector Catch. > Also, they do not support other "clean" reset-halt methods such as > connect-under-reset. > > Oh the joys of ignorant hardware designers with their "clever" solutions. Why not just stick with the established practice? "PSoC6 Programming Specification" document describes alternative > acquisition method which can be used with third-party probes: > 1) Halt the device > 2) Read Vector Table Offset register and calculate location of ARM Vector > Table (vt_addr) > This assumes the currently running application has not remapped the vector table. This is common to do in e.g. a bootloader before starting the application. The bootloader may even behave differently the next reset (detecting the reset and starting a fail safe application). > 3) Read (vt_addr + 4) location to determine entry point of user > application (app_main) > 4) Set HW breakpoint at app_main > 5) Issue SW reset by asserting SYSRESETREQ bit, device will execute boot > code and will halt at breakpoint > This assumes that the flash already contains a valid application. What if it's empty or containing garbage? The reset vector would probably point to an invalid location which will never trigger the FPB. > 6) Remove the breakpoint, write infinite loop opcode to RAM, adjust PC, LR > and SP registers. > 7) Set THUMB bit in xPSR > 8) Start the CPU. Now PSoC is running infinite loop with all peripherials > in disabled/reset state. > > I've tested this procedure with OpenOCD and several JLink probes (Ultra+, > Basic, and cheap Chinese fake) and it works flawlessly. > > What is the problem with 1) Halt the CPU 2) Set up safe execution state with infinite loop opcode in RAM 3) Start the CPU ? /Andreas |