Swap functions on MK22FN1M0 and silicon revisions

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Swap functions on MK22FN1M0 and silicon revisions

Jump to solution
910 Views
randylee
Contributor V

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 which returns fine and the FCC0B5 register is saying UNINIT.  This then attemps to do the initialize abot with address 0x7F000 which is setting the ACCERR bit doing it.

 

Labels (1)
Tags (1)
0 Kudos
1 Solution
863 Views
randylee
Contributor V

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.

 

View solution in original post

0 Kudos
2 Replies
864 Views
randylee
Contributor V

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.

 

0 Kudos
846 Views
PabloAvalos
NXP TechSupport
NXP TechSupport

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.

0 Kudos