K64 - What's special about code address 0x10000

[JHinkle]

I'm writing a Bootloader with the code size ending up around 45K.  I wanted to start the Application code on a 4K boundary (K64 flash sector size is 4K) so I selected address 0x10000 to be the location of my application (or so I thought).

Address 0x10000 is the 64K boundary.  I'm using a 1 Meg K64 cpu.

I want to do a simple test to see if the Application could be loaded so I test the first byte (stack size in vectors) to see if its 0xFF.

byte *p = (byte*)0x10000;

The assembler code for this results in a HardFault when performing an indirect memory read from a register (register holds 0x10000)).

My debugger (Crossworks) says "Memory Read Failure" when asked to show *p.

When the debugger is asked to dump any memory location between 0x10000 and 0x100010 (first 16 bytes of the second 64K memory block) -- it shows all blanks and reports read error.

If I change my Application's starting address to 0x11000 (64K + 4K) --- all is well.

Can someone explain what's happening at address 0x10000?

I don't want to start the application code lower than 0x10000 if I don't understand what the issue is with those 16 bytes.

Thanks in advance for any help/comments.

Joe

[JHinkle]

I would like to understand what could have gotten written to in Flash memory that would cause this to occur.

I use JLink - so asked to totally erase the chip.  Once that was done, the memory was able to be accessed as expected.

I was developing the "Main" Application.  Then I began developing the Bootloader.  The bootloader code was flashed into the proper bootloader memory space but the "main: application code remained in flash that was outside the bounds of the bootloader.

As I stated earlier, if anyone as an idea of what could cause this behavior - please comment.  I would like to understand what happened because a totally erase may not be possible in the future.

Thanks.

Joe

[mjbcswitzerland]

Hi Joe

The K64 memory will become corrupted if you try to do an illegal operation (eg. trying to reprogram a value that is not initially 0xffffffffffffffff). The result is that it will cause a hard fault when accessed and you need to delete the sector (or even do a mass erase) to recover.

This doesn't happen on all parts - mainly the newer ones - and I suspect (although Freescale/NXP never uttered a word about why it happens and if the suspicions are vaid) that it is the way that the internal Flash ECC operates (NXP will know since their LPC Flash does this with 128 bit lines as they have published). When you modify a phrase that has alread been written once it means that the ECC no longer matches and the Flash controller declares a line of memory to be corrupted.

Note also that there are many boot loaders available for your chip at http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF in case you would like to save time with a proven solution or use as reference to solve your own development problems. For 45k Flash you could have Ethernet, USB host/device, SD card and UART loading all at the same time.... (and be finished by this evening)....

Regards

Mark
Kinetis for professionals: http://www.utasker.com/kinetis.html

[JHinkle]

Thanks Mark

The memory space at 0x10000 was previously programmed and contained non-FF data.

The post above was not speaking about trying to program that space -- I was attempting to read it's contents to determine if it was erased or previously written to.  A simple read operation produced the hard fault -- hence my investigation as to why that 16 byte (128 bits) of flash memory was unreadable.

Thanks for the offer of a bootloader but I usually roll my own.  Then I'm the only one on the hook if it doesn't work.

My bootloader is a custom loader that communicates with a UDP server to acquire the encrypted files to flash into the K64 and perform post-assembly testing - (log K64's unique chip ID to a database, assigns a unique MAC address to the device, load final code, etc)

I hope NXP provides you some income since you are about the only person that responds to questions.  Since NXP purchased Freescale, the "Factory" support for this forum has really down down the tube!!!

Thanks for all you do.

Joe

[mjbcswitzerland]

Hi Joe

To re-confirm. Flash (in certain newer parts) will give hard faults if 'previously' it was incorrectly programmed, so whatever software or debugger tries to access it as a read it will cause the error. After a mass-erase the complete flash should be Ok again so it doesn't point to any problem with your loader as long as it didn't cause the original error (or previous versions didn't).

>>I hope NXP provides you some income since you are about the only person that responds to questions.  Since NXP purchased Freescale, the "Factory" support for this forum has really down down the tube!!!

I don't think that the support has deteriorated, but the forum seems to be mutating more into how to get the Freescale/NXP code to actually work rather than technical (and more interesting) chip/peripheral issues. The way of semiconductor companies during the last years has been to try to give customers a black-box which magically generates code, dumbing down the users so that they can only actually get things working when this happens to work or they have the time to invest in actually filling in the learning gap to make progress. In fact I think that there are many more NXP employees that are supporting the forum recently and some are obviously knowledgable in some areas but also seem to get stuck when the magic stops working and then write that they are "passing on the question to the 'team' who did that part". Sometimes they do get back but quite often not, or only after weeks or months.

The strategy may be not the best for developers who end up being dependent on tools to solve even quite simple problems and cannot move to other devices (including competitors) because they know (and also their employers who are funding this know), that it would be a too great learning curve (also read as costly). The strategy is however good for semiconductor manufacturers since new customers think that they are getting everything handed to them on a plate while they are in fact often getting "locked in" so that it is too late later when they realise how much their development with all the free code thrown at them will actually cost to get it finished, so they just plow on anyway.

In fact I have been a Freescale Design Allicance Partner for 10 years and worked closely with various FAEs (they come and go so many of these are now with Atmel, Texas or similar) and have supported around 1'000 Coldfire/Kinetis projects during the period (some delivering code and some taking on new protocol developments or in some cases complete product development). In various projects I managed to convince customers to move to the (in my eyes) better Coldfire or more recently Kinetis environments (often the origial intention was to use something that they already knew from ST or Atmel etc.) and supply complete operating environments to give them flying starts. Together with Freescale FEAs we organised eval boards to get started with (which I could get at reduced rates as a Partner at the time) and I experienced many efficient and reliable product developments, with many original Coldfire users now having migrated to Kinetis where we are still active on new product developments as continued collaborators.

The world changes though (also before the NXP takeover). Freescale originally worked closer with partners, offering reduced evaluation boards as well as pre-release examples and information. Over the years I have invested about $10k in Freescale development and evaluation boards and was very pleased to sometimes get first pre-release versions free so that I could get some experience and port my own code to so that we could start using them faster for new work. More recently (again before the change) the focus changed to what seems to be an internal struggle to get up an internal software framework available (based on foreign OS, open-source stacks and such) and gradually any advantages of being a software development partner have deteriorated (no more reductions on hardware or contact concerning new parts to be released shortly).

A few weeks ago I received a letter from NXP saying that they have reviewed our parnership and have decided to terminate it, so at least I have nothing more to compain about. Initially I thought that I should explain to them how many new customers that I had helped to win for Freescale over the years and the many hundreds (or thousands) of products that I helped get to market faster (I have no idea of how many millions of parts that have been involved) but decided that it was not worth the effort anyway. So now I am pure free-lancer (zero NXP ties either contactually or morally) and have my own greater freedom in being able to choose to better support other chip lines if I see fit (I do like the Kinetis though so do this because I really enjoy it). When one gets older I think that one learns to accept things that one cannot change anyway.

If there was one thing that would sometimes be nice it would be to have a small recognition - for example, I have many industrially proven solutions that Freescale/NXP SW simply can't match. When I point this out to someone who (may) be able to benefit from it as an 'off-the-shelf' solution that they can have even for free if needed [eg. a USB host boot loader for a K21 to build with Rowley Crossworks] someone from NXP will then write that they highly recommend the user to take an application note example that runs on a K60 and builds with IAR and port it as being the "preferred solution". I see absolutely no way that that is in the interest of NXP (or the customer) to advice to embark on a further porting adventure (which may equate to several weeks of work and project delay with no guarantee of success) rather than take something proven so that they can get to market quicker (and potentially more reliably) and ultimately sell more of their and NXP's products. However there are literally hundreds of such posts - one of my US customers actually said to me once that they had seen such a post where in his opinion "that  'stomped' on you there".

Anyway, that explains the Flash stuff ;-)

Regards

Mark

[egoodii]

As Mark says, a hard-fault-on-Flash-read is 'almost always' due to double-writes in a phrase (OR in certain circumstances a failed-write due to power-loss-during-write).  Erase 'at least the sector' and try your process again.