We can read the chip version just fine but any other command results into 0E error code, which doesn’t mean anything in the manual!
But since you said something about the platform, yes it has an issue and we fixed but still waiting for the next sdk release! I will try it with the fixed platform as this is the only logical explanation.
I have moved two arrays from being local variables in the function into the IAP class.
Now they are allocated on the heap (closer to the beginning of the address space) instead of the stack. I was able to write to EEPROM and read back!
This is what got us completely off. The stack was always wrong, due to memory set incorrectly in the platform by the first clone mbed provided to us. Nothing should have worked but everything seemed to work fine until last week where Jeff kept getting unexpected crashes. I then found the wrong settings and fixed them, waiting for acceptance on the pull request from mbed.
It never crossed my mind that this wrong setting is also effecting the IAP! I am glad things will make sense from note on thanks for the hint.
Speaking of memory, I think mbed also forgot to reserve memory for the stack, not just in our platform but in every other platform I looked at! I mentioned it to them but they didn’t seem interested! Anyway, both issues are covered in our platform.
The stack issue is resolved. It will be available in the next sdk. You can use today by pulling in the core source code in your project. Just a FYI notice.
@ taylorza - He didn’t email @ Architect, he is telling everyone on this thread…lol And it’s part of my job to keep some of the information a secret until we as a company are ready to talk. 8)
@ Jay Jay - LOL, you got it, Gus is sending me around the world to meet the different members who contribute to this community. And if you are lucky enough to have made the list feel free to donate to my vacation fund! 8)