I'm using the swap facility on the MK22FN1M0 parts to implement bootloaders. Most parts this works fine on. I've got some parts that it gives me problems with and it appears to be something with a silicon revision... Specifically 2N03G doesn't usually work and 3N03G usually does. Not clear if this is the real problem but...
The command that eventually gives me problems is using the Freescale functions _PFlashSwapCtl() and related.
It ends up sending a flash command sequence to FCCOB of: 0x46 (FTFx_PFLASH_SWAP),addr MSB, addr, Addr LSB, 1, 0xFF, 0xFF, 0xFF
the FSTAT register comes back with a status of 0xA0 (setting the ACCERR bit).
So the question here is if there is some change to behaviour of the swap system over the various silicon revisions...
Also we've had 2N03G parts that have worked until we reprogrammed them with a J-Link flash (SWD) and then it stopped working. We have no problem programming 3N03G parts this way.
Going thru this closer the application first checks status of the swap system (swap command
Solved! Go to Solution.
I think I got it.
What I ended up doing was taking the errata literally and punching a hole in my hex file down ever the top of the vector table of a reasonable size. The tools sets being used here (KDS3) generate sparse hex files so it did not generate loading instructions for that address range and because the j-link software is using sector erases of the flash, it leaves that flash un-written completely. I then am pointing into this area which is substantially below bit 18 and it works correctly!
Prior I was pointing to 0x7F00 and now I’m pointing to this hole at 0x200 and making SURE that nothing is writing to it once erased.
I think I got it.
What I ended up doing was taking the errata literally and punching a hole in my hex file down ever the top of the vector table of a reasonable size. The tools sets being used here (KDS3) generate sparse hex files so it did not generate loading instructions for that address range and because the j-link software is using sector erases of the flash, it leaves that flash un-written completely. I then am pointing into this area which is substantially below bit 18 and it works correctly!
Prior I was pointing to 0x7F00 and now I’m pointing to this hole at 0x200 and making SURE that nothing is writing to it once erased.
Hi @randylee
Thank you so much for using our community.
It sounds really nice that you got it solved. So please, if you have more questions, let me know, otherwise, please mark this answer as solution. You are always welcome to our community to open new threads with new questions so we can help you with.
Thank you.
Best Regards.
Pablo Avalos.