I’ve been tripped up porting some existing code to an FR5964. This is code that has run happily on the older 4 series, and the non-FR 5 series, but I’ve been having problems around interrupts on the FR – basically it disappears into la-la land as soon as it hits an interrupt. As this is the first play I’ve had with the FR processors, my initial thoughts were that it was something specific to the FR’s that I was missing (akin to the LOCKLPM5 needed to release the GPIO’s on startup). However, I’m not totally convinced this is the case.
To try and get to the bottom of this, I stole the initialisation code for the FR5994 evaluation board, and pared this down to some simple code, which does nothing more than initialise the MCLK and SMCLK, then enables UNMI interrupts. This immediately fires (not sure if it should do this, or its just the DCO settling, but that is a secondary question). I can catch this with the debugger, but any attempt to step past the ISR entry point immediately aborts.
I’ve followed this through the UNMI vector, which is correctly initialised to the ISR address (just happens to be 1C36). What is at the ISR memory looks like rubbish, and the disassembly in CCS looks nothing like a valid ISR. It took me a while to figure out that the ISR has actually been placed in RAM (starts at 1c00 on these processors), and that what I am seeing is pretty much uninitialised RAM being treated as code. While it would be technically possible to run the ISR’s from RAM in these processors, I assume it would need some of the non-volatile storage support to enable this, and I would hardly expect this to be a default. I haven’t found any references anywhere to this behaviour, so I’m still tilting towards some option (probably linker related) that I have wrong.
Can anyone explain what is happening here, and more specifically any hints on where the problem lies and how to resolve it.
BTW, I’m using the GCC toolchain 9.2.0.50, and CCS 9.3.0.
Thanks and regards - Andrew