In November, we had a problem that the program runs away, but this was caused by a wrong debugger start address which was set in the example.
We got the advice to change the debug start address to 0xffff0000, and this solved the problem.
At the moment we extended the team and start using more Evaluation Boards.The problem is that 3 of the 6 boards we have still have (about the same) problem.
When we start the program, it runs away soon (loops at 0xffff0004).
If we click the debug reset button (in e2Studio), it stops (now at address 0x21000000, vector_table) and we can start it.Then it runs for a few C statements and function calls, and then runs away, somewhere around address 0x230c0000 (many 'addeq r0, r0, r0' instructions, thus 'nonsense').
When I step through the few C statemensts, one time I saw near a instruction 'bx lr' that it jumped to another address then the contents of lr.
Strange things happen.
Is something not correctly initialized that it depends on 'random' contents of memory in the boards ?Or is there indeed a known issue with this.Our program came from 'blinky osless', but we think it is a problem in the hardware / debug environment.
We hope to get a solution
We think having fount the cause.
In our Project Settings, in the Run / Debug Settings - Startup, loading the Boot Loader was dropped (we don't know why and how...).
On the boards working OK, already another projects was loaded before, so the Boot Loader was present in it.
It probably does some initializing of the Serial SPI Flash, required for correct accessing this memory by the application.
Thus this (afterwards some 'silly') problem may be marked as 'Resolved'.
Hi HvdB,I have the same problem on a board from M13 design (RZA2M-EK). Please can you tell in detail, what I have to adjust in e2studio to run the project in Debug-Mode?
Thank you very much
Edit: Problem is solved with reinstall the latest e2Studio-Version 2023-01(23.1.0)