I wanted to try to get the M4 (in a Vyvrid VF6) running with IAR in debug mode but there are some strange things going on. Therefore I am wondering whether anyone else has worked with IAR and has solved these issues?
1. If I take an IAR example that simple adds a main() with return 0; in it all is fine.
2. When I add my own reset vector table (replacing the one in the rt7m_tl.a library) I can load the code and see that the reset vectors are correct in RAM the debugger shows a different SP value and also the PC is set to what looks like a location in the ROM loader (about 0x5000). Therefore I can only debug when using the library vector, even if the values are the same. This means that the code can only be run/debugged by first manually correcting the SP and PC but it is not possible to command a rset - instead the code needs to be re-loaded. Strangeness 1.
3. Often when I load my own code there is a fatal error and the debugger says that it can't write to 0x3f000000. This is the first location in SYSram0 - if I connect without loading code, this location can be read and written by the debugger.
What I tend to find is that loading the original IAR demo is possible and then I can also load my own code again, until it maybe stops accepting it agan later. Strangeness 2.
4. I see that the default reset vector that the IAR library supplies contains the vectors up to and including the SysTick handler. It doesn't contain any peripheral interrupt vectors.
This means that code or variables are located from 0x3f000040 (after the basic vectors).
When peripheral interrupt are inserted they then overwrite code/variables and cause failure.
What I did to avoid the probelem (and still have all vectors located at the start of RAM) was to modify the linker script to reserve space for the peripheral interrup vectors, which is probably OK as a solution, but I am wondering why the initial situation effectively excludes any interrupts after SysTick to be able to be used?
Anyone with IAR experience who can shed some light?