Re: [OpenOCD-devel] PSoC6 support: NOR flash driver question

[Andreas F. <and...@gm...>]

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