New
Hi,
we have a bit of a problem with FWs larger than 57344 bytes (0xe000 in hexadecimal), that run XIP from flash, and we connect to CM4.
We were also able to reproduce the problem with an example SDK (which I attach) on MCUXpresso IDE v11.10.0 [Build 3148] and running on EVKB, and JLink (tested 7.98h and .7.96o)
In fact, the FW resides in flash at address 0x08002000 (but I have also tried having it reside at 0x08012000, with the same results)
The flash is correctly written in all cases. If the FW is smaller the JLink debugging session starts without problems. While with larger FWs it does not, and the Program-counter we find it at an address of 0x2020xxxx, where the JLink RAMCode should reside
but we didn't map anything there.
To implement the FW “bloat” I used an array, not used by anyone in the code (so as not to alter it), but present in the executable thanks to a special KEEP() directive on the linking options:
If the id 39676 threshold is exceeded, the flash image exceeds 57344 bytes and what happens is that it doesn't get to the main because the PC stays somewhere in 0x2020xxxx
An interesting coincidence is that the FW, as mentioned resides at 0x08002000, and so exceeding the size 0xe000 means exceeding 0x08010000, an oddly round number. For these reasons, we tried to place at 0x08012000 but did not notice any change.
can you also try it and help us figure out where we are going wrong?
regards
Max
we have a bit of a problem with FWs larger than 57344 bytes (0xe000 in hexadecimal), that run XIP from flash, and we connect to CM4.
We were also able to reproduce the problem with an example SDK (which I attach) on MCUXpresso IDE v11.10.0 [Build 3148] and running on EVKB, and JLink (tested 7.98h and .7.96o)
In fact, the FW resides in flash at address 0x08002000 (but I have also tried having it reside at 0x08012000, with the same results)
The flash is correctly written in all cases. If the FW is smaller the JLink debugging session starts without problems. While with larger FWs it does not, and the Program-counter we find it at an address of 0x2020xxxx, where the JLink RAMCode should reside
but we didn't map anything there.
To implement the FW “bloat” I used an array, not used by anyone in the code (so as not to alter it), but present in the executable thanks to a special KEEP() directive on the linking options:
If the id 39676 threshold is exceeded, the flash image exceeds 57344 bytes and what happens is that it doesn't get to the main because the PC stays somewhere in 0x2020xxxx
An interesting coincidence is that the FW, as mentioned resides at 0x08002000, and so exceeding the size 0xe000 means exceeding 0x08010000, an oddly round number. For these reasons, we tried to place at 0x08012000 but did not notice any change.
can you also try it and help us figure out where we are going wrong?
regards
Max