Hi, I am working on project DA14580_BEACON_3.40.6 recently, and I found some strange things. I add some code by myself, such as external interrupt pins, encryption handler and so on. When CFG_SPI_FLASH is undefined, the code runs well and all the results are what I expect to get. But when I define CFG_SPI_FLASH, the code runs strangely which I can't see the logic in it, and what' more, the code compiles successfully.
So, my question is, is it true that the code size is out of limit which is defined in scatter files?
compile result when #define CFG_SPI_FLASH
Program Size: Code=25428 RO-data=1384 RW-data=108 ZI-data=7388
compile result when #undef CFG_SPI_FLASH
Program Size: Code=22552 RO-data=1300 RW-data=108 ZI-data=7300
I really need some help, so if there are any suggestions, please show your kindness.
I get compile errors when my code is too big. If the actual code is too much, I will get a slew of errors that appear as shown in my post here:
http://support.dialog-semiconductor.com/getting-not-enough-room-error-32...
If my data arrays are too big I get another set of errors. These errors are more obvious and it means that one has exhausted what appears to be the 8K (0x2000) of retention RAM and the additional 0x1000 bytes of 'ordinary' ram on top of that. Since you are getting no build errors (actually they occur while linking) it suggests that there is something else going on.
I know I have made it look like the DA14580 had more memory than it did by changing the scatter files just so the link would complete and I would get a map. When the linker fails with memory limits you get no map so you can't see how things are laid out. On the other hand the last error on the code size limit case
\out\full_emb_sysram.axf: Error: L6407E: Sections of aggregate size 0x300 bytes could not fit into .ANY selector(s).
indicates that I am short 0x300 bytes and need to shrink my code by that much. Reducing array size won't help here.
I have also noted some other strange behaviors that in my case and maybe some others I have read on the this forum usually cause hardfaults or a total system death as on a stack overflow. Look to see if one of your data ARRAYs are located just in front of the space allocated for some of the system heaps in the map file. I have several cases in where I have seen problems arise when that is the case (usually hardfault). Since one has no control over the placement, the only thing I could do was play with the code and hope the linker would layout items differently. In one case changing an array from 104 to 100 bytes caused the linker to move the array away from the non-retention-memory heap. Then everything worked like a charm. At 104 the system hard faulted. The only call on the array was memset(array, 0, BUF_SIZE). The map stated BUF_SIZE was correct. Note, this is all by experience; I have no explanation and have not received any feedback yet from Dialog.
First, thanks for your detailed explanations, you're a nice guy. Second, I find that the reason is that periph_init(); isn't called periodically as it's in 3.40.2 project, therefore, my external pin interrupt can't be configured normally as it used to be. Yes, it's not the memory limit but some changes taken place between 3.40.6 and 3.40.2 version that causes my problem. Hope that will help you to some degree.
Finally, I find out the real reason why periph_init(); isn't called periodically as it's in 3.40.2 project. It's because SPI FLASH disable sleep mode for 5s, but I commented the poweroff timer, so the whole system isn't going to sleep mode anymore !