> Oh the joys of ignorant hardware designers with their "clever" solutions. Why > not just stick with the established practice?
100% agree with you. I have no idea why Cypress decided to use this technique. > 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). In addition to standard VTOR register in System Control Block, PSoC6 devices have CMx_VECTOR_TABLE_BASE registers. These registers are populated by boot code so they point to start of user application. They are not intended to be used to remap Vector Table at runtime (by bootloader, etc), user application should use VTOR register instead. Flash driver code uses CMx_VECTOR_TABLE_BASE (not VTOR) to find application entry point. Of course user application can alter value in CMx_VECTOR_TABLE_BASE, in this case 'alternative' acquisition method will not work. This is the limitation. > 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. This situation is handled in flash driver code. Driver will not set any breakpoints if either value in CMx_VECTOR_TABLE_BASE is invalid, or address of ResetVector is invalid. In this situation it will just start execution of infinite loop in RAM. > 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 The drawback of this method is that all HW and also second CPU core are left in unpredictable state. PSoC6 device is dual-core (CM0+, CM4) and both cores share the same address space (same Flash/RAM regions, etc) so CM4 can easily corrupt CM0s stack or RAM buffers used for Flash programming. CM4 core is disabled after reset and it should be explicitly enabled by user application. Also, memory protection units can be configured in a way to block debugger access to RAM and/or MMIO registers. The only way to overcome this issues is to use clean reset-halt procedure. And the only way to reset everything in the system and cleanly halt CM0 is to use 'alternative' acquisition method. This method is not my 'invention' =) it is described in "002-15554 PSOC(R) 6 MCU PROGRAMMING SPECIFICATIONS" (not in public access currently, PSoC6 is very new device so things may change). Best regards, Bohdan 2017-09-25 17:48 GMT+03:00 Andreas Fritiofson <[email protected]>: > > > On Mon, Sep 25, 2017 at 12:39 PM, Bohdan Tymkiv <[email protected]> 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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
