Thanks Maclain,
I cannot begin to tell you what a relief I got after seeing your designation. Now I have email chains which date back to 2 months. How should I hand them over to you (some private area) ?
And yes, 32KHz clock issue seems to be digested by MQX team.
Anyway, summary of other issues:
- SRAM partitioning issue with MQX 4.1.1/MQX 4.2:
We see processor reboots whenever any variable with dynamic allocation crosses SRAM lower to upper boundary (spread across 0x1FFFFFFF) and we try to memcpy.
In order to avoid that, IAR suggested using linker file which partitions SRAM to upper and lower regions and keeps HEAP assignments in one of the regions. WE as a company do not agree with it, reason, our STACK could be bigger or slimmer and could or could NOT fit in LOWER/UPPER region why should we unnecessary waste 1 of the regions by allocating HEAP or STACK only to one of it.
So, in order to avoid using linker config file solution and wasting memory regions, I came up with a simple solution, place a dummy variable @ SRAM boundary between lower and upper regions (for my K64 it is 0x1FFFFFFF), it works FINE. No issues. But we need blessings from you and IAR folks that it is OK to use this method and we will be safe. Can we get that ? Also, we had concerns if we use memcpy from lower to upper memory region variable copying or vice versa but recently after talking to Doug it seemed like that is not an issue but boundary crossing still remains an issue.
Can we put our product into production using dummy variable placed across memory boundary ?
We expect SRAM U/L access issue (I hope you are aware that the root cause of this issue is Freescale uses 2 different buses to access these 2 regions, I think CODE bus and SYSTEM bus) to be handled by IAR/Freescale not by application makers like us.
CONFIRMATION, that it is a MQX issue:
Ok, I thought more about this.
I think in _bsp_init function of MQX a call is made like this:
/* Memory splitter - prevent accessing both ram banks in one instruction */
_mem_alloc_at(0, (void*)0x20000000);
This call’s success or failure is NOT acted upon, I debugged it and found to my dismay that it FAILS but MQX code does NOT care if it fails or NOT and that is the core reason that my code later ON can get access to memory boundary in SRAM.
Please see the video here (and please share this video with your developer): https://www.dropbox.com/s/kk88c8lcwj3uvgy/_bsp_pre_init_MEMFail.mp4?dl=0
2. Kinetis Bootloader issue:
We have another one for the Freescale/IAR team.
Here is the code snippet:
#define SOFTWARE_VERSION_SIZE_BYTES 18
const char SOFTWARE_VERSION[SOFTWARE_VERSION_SIZE_BYTES] @ ".MainSoftwarVerLoc" = {"APP.000.0016.0000"};
#pragma required=SOFTWARE_VERSION
If I use this code and build a binary and use FSL Kinetis bootloader WINDOWS APP (v 1.0.2) to flash it, everything is fine.
BUT, If I delete the location for that variable by deleting the red text above, a new SREC file is generated.
And this new SREC file flashes OK (at-least that is what my Windows PC application of Kinetis bootloader states) with FSL Kinetis boot loader but my application does not run, I dug deeper and found the issue is while flashing the new SREC file (which does not have .MainSoftwareVerLoc defined), Kinetis bootloader skips the Interrupt vector table for my APP (IVT is @ 0xA000) but still states everything is OK.
Why is Freescale Kinetis bootloader stating that everything flashed OK with new SREC although it skipped flashing IVT @0xA000 and why did it skipped that location with new SREC file ?
Attached are the MAP/SREC/ICF file with and without MAINVErsionString defined (their names are self-explanatory).
