Bootloader don't write whole Flash

Hi Roger,

you really have a 4 years old EK-LM4F232?

Did you checked your linker command file? The values there should match the ones in CCS | Project Properties |  CCS Build | ARM Linker | Basic Options. And, btw, the linker command file in StellarisWare\boot-loader\bl_link_ccs.cmd contains wrong values for Flash and RAM length in our LM4F232 case.

Were you able to program a full flash image at some time in the past or was this the first time you've tried it? I seem to remember some bug that we fixed a few months back that related to an incorrect size test somewhere and this caused you to be unable to program the last 1KB page of flash. I can't remember if this was in the bootloader code or in LMFlash. I'll try to find this bug report but, in the meantime, you may want to check that you are using the latest release of LMFlash and boot_usb.

I found the problem I was thinking of but it related to the Ethernet boot loader and an error in the TFTP protocol it uses. I'll try to reproduce this and see if I can see a problem here.

Juergen Gaertner said:

you really have a 4 years old EK-LM4F232?

The label on the Box has a date from 2009, so I think the Board are also from this year. :)

Juergen Gaertner said:

Did you checked your linker command file? The values there should match the ones in CCS | Project Properties |  CCS Build | ARM Linker | Basic Options. And, btw, the linker command file in StellarisWare\boot-loader\bl_link_ccs.cmd contains wrong values for Flash and RAM length in our LM4F232 case.

I load the complete StellarisWare from http://www.ti.com/tool/sw-lm3s.

The length for Flash and RAM in that file are not correct for the LM4F232, but I don't need this. I took the .bin file, that is already compiled in the boot_usb directory.

Dave Wilson said:

Were you able to program a full flash image at some time in the past or was this the first time you've tried it? I seem to remember some bug that we fixed a few months back that related to an incorrect size test somewhere and this caused you to be unable to program the last 1KB page of flash. I can't remember if this was in the bootloader code or in LMFlash. I'll try to find this bug report but, in the meantime, you may want to check that you are using the latest release of LMFlash and boot_usb.

I'm using the boot_usb from the complete StellarisWare from 11-Sep-2012. That's the latest release I found. 

I had often programed a full flash image with the ICDI and the bootLoader. I had also used the two boot_demo examples and all worked fine. But after a week, the problem with the flash started. 

I have an other LM4F232 Evaluation Board now and it works all. Hence, I think something with the Evaluation Board is wrong and the software should work.

Because I can still program with the ICDI and only the bootLoader doesn't work, I can use it for other projects.

I hope it doesn't happen again. :)

To send the flash image to the Evaluation Board I used the LMFlashProgrammer and the dfuprog from StellarisWare and both end in the same result.

I'm confused, because the flash works fine if I use the software without the bootLoader, but with the bootLoader it seems that the flash are corrupt.

Roger

FYI, the ek-lm4f232 board was introduced in September 2011 so I don't know how you found a 4 year old one :-)

I think I need to clarify exactly what is going wrong. I assumed you were trying to flash an image whose size was exactly the same as the available flash on the device and that, when you do this, the top 1KB is not written. Reading this again, though, I don't know if you are flashing a large image that completely fills flash or just an image of a whole application. I'm also unclear about where the bad 1KB block or blocks are. Are the bad blocks always at the same address? If so, where is this? Does this correlate to the last 1KB of the image you are downloading or is it somewhere else in the application?

Using LMFlash, it sounds as if you can correctly program application images from the StellarisWare release using the ICDI option. You also say that you can use the bootloader to flash successfully too but you mention that boot_usb doesn't work. Could you let me know which bootloaders are working correctly for you and which are showing the problem?

Are you seeing these problems using the binaries included in StellarisWare or applications and bootloaders that you have built yourself? If the problem is only seen in your own applications, look carefully at the examples and see if you can see what differences exist between your application and the working exaxmples. Look, particularly, at the linker settings.

Thanks for your help, but I can't continue with testing, because we now working on an other project, but here what I had testet:

I used the three examples from StellarisWare: boot_usb, boot_demo1 and boot_demo2

On the new LM4F232 Board this works. I can load the boot_usb and boot_demo1 on the Board and use the LmFlashProgrammer to switch the software between demo1 and demo2. The LmFlashProgrammer sets the address offset to 0x2800 if I choose USB DFU and that's correct.

But If I try exact the same with the other LM4F232 Board, it doesn't work. I can load the boot_usb and one of the demo examples and that works. It changes correct in the DFU Mode. Now I use LmFlashProgrammer to Update the Firmware over the USB OTG plug and it returns no errors or warnings. BUT the Display are black -> doesn't work. Then I upload the whole flash content with LmFlashProgrammer and open it with a hex editor. At a random position in the flash content of the demo application is exact 1kB 0xFF.

If I load the qs-logger example, which is larger than the boot_usb and one of the demo examples, it works fine too.

My Conclusion:

The examples boot_usb and the two demo works. So I think something with the LM4F232 Eval Board are not correct anymore.

I heard, that in the past the flash was used to save some data. Maybe the 100'000 write cycles are reached or so...

For me, this topic is closed, because I have no time to continue with testing. But if you have an idea what the problem might be, I would be interested.

Thank you

kind regards

Roger