IAP fails after 8k of programming

[daniel8]

Posted on April 24, 2008 at 19:01

IAP fails after 8k of programming

[daniel8]

Posted on May 17, 2011 at 09:52

Hello. I am running the IAP program in crossworks, and I am having a hard time getting it to work.

I am attempting to get the IAP to work on a str912faw44x6, and after 8k written it does not update the flash anymore. It can successfully write out 8k worth of data, but when it gets to writing the 9th packet (to address 0x000820000), it fails - the flash is always blank (0xFF) after that point. Has anyone seen anything like it?

[najoua]

Posted on May 17, 2011 at 09:52

Hello daniel2,

I suppose you are speaking about the IAP driver provided by ST and which is published on the ST91x web page. You said that a write to address 0x000820000 is failing. I suppose you mean 0x00082000 and not 0x000820000. The behavior you are observing is strange. The IAP driver allows downloading files without problems except files having a size between 64Kbytes and 128Kbytes (see description below). It is a bug in the IAP driver which will be corrected in the next release: When the file to be loaded in the Flash using IAP has a size <=128Kbytes and >64Kbytes (i.e. the 2 sectors S0 and S1 are needed), there is failure of the download-->this is due to the fact that there is a line missing in the IAP driver corresponding to the write un-protection of S1. Now, to investigate more the problem, could you please: - tell me if you performed hardware remapping of both Bank0 (at address 0x80000) and Bank1 (at address 0x00) prior to loading the IAP driver? - try to load files having different sizes and see if the same behavior is observed? - send me the ymodem.c source file to check (if you made any modifications of course)? - tell me what your image size is? I am waiting for your feedback. Best regards, Najoua.

[daniel8]

Posted on May 17, 2011 at 09:52

Indeed, the address is 0x00082000 (my typo).

I had seen the bug for code > 64k, and the file in question was about 56k I did try loading a file that was less than 8k in size, and that seemed to work fine. There were no modifications done to ymodem.c - I changed 91x_fmi.h to remap bank 1 (otherwise the moment you erase the bank of memory you kill your program 🙂 ). I am using crossworks, and I am using their jtag loader for bank1 (which seems to work fine - it loads the program where its supposed to). The only other modification to the standard IAP code I had to do was to change the RAM_exe define to match the way gcc wants to set things into ram. I was reading up on the forums , and there were some issues with running some parts at 96Mhz and the flash wait states. This is a Rev. G part, so I am going to do some investigation regarding that. All else failing, I will load the code into IAR and run it from there, and just see if its some idiosyncrasy with crossworks or just a problem with the particular silicon that I have. I thank you for your reply. Daniel

[najoua]

Posted on May 17, 2011 at 09:52

Hello again daniel2,

I didn't understand your statement ''I changed 91x_fmi.h to remap bank 1 (otherwise the moment you erase the bank of memory you kill your program 🙂 )''. The remapping is already done in the 91x_fmi.h header file. Normally, the IAP driver is located in Bank1 located at address 0x00 and your application is loaded using IAP in Bank0 located at address 0x80000; consequently I am not seeing a risk to kill your program. Could you please clarify? Regarding the frequency, in the IAP driver provided by ST, the CPU frequency is 25MHz. Did you change the driver to make the CPU work at 96MHz? The fact of testing your driver on another Toolchain is a good idea in order to confirm if the problem is Toolchain related or no. Please let me know how it goes. Regards, Najoua.

[daniel8]

Posted on May 17, 2011 at 09:52

When I first ported over the code, I was using the standard library and the define was to use bank 0, so the first time I executed it it crapped out due to the fact that it erased the bank it was executing out of.

Anyway, no, the system is still running at 96Mhz (which could be my problem), and I am looking into that. The odd thing was I loaded the example into IAR, and when trying to run that with the segger j-link, the program does not run at all. I removed the checks for the joystick and edited the serial port to work with the olimex board I have, so it should always go into the menu to reprogram. After building it, and programming the jtag, when I run, it just stays in the reset vector, never executing the code, so something else is afoot there. Anyways, I am going to be doing some debugging at 25Mhz and find out if that was my problem or not. The one thing that really bugs me is the fact that the IAR code just wont execute at all - and I tried two different boards there..but we will see..Thanks for the help again Daniel

[najoua]

Posted on May 17, 2011 at 09:52

Hi daniel2,

Could you please attach your example compiled with IAR to check? Regards, Najoua.

[daniel8]

Posted on May 17, 2011 at 09:52

Sorry for the delays, but I have been out on a different matter. Anyways, I will post the code soon, just wanted to update you in the meantime that I coded the flash loader using the crossworks libmem functionality, and I also see the same thing. Since I know this code is what's used on their regular loaders, I am assuming there is a switch in crossworks that I am not setting properly that is causing this to happen. Once I talk to them I should be able to figure this out, otherwise I'll probably run it on IAR to at least verify that the part isn't damaged or something.

Daniel

[daniel8]

Posted on May 17, 2011 at 09:52

Ok..here is what I am at. I verified that for some unknown reason, only the first 8k were unprotected, and hence when the erase went through, only those first 8k were writable later on (which is very odd to me since this is supposed to be a 64k sector size). Anyway, by issuing the PRP and unprotect commands to address 0x80000, 0x82000, 0x84000, etc, I was able to then erase the entire sector and write the flash properly.

I don't know why that is the case, but I'll continue now to finish the IAP and see if I can get it to run properly.

[daniel8]

Posted on May 17, 2011 at 09:52

Ok..so here is the moral of the story. The STR was booting out of bank0 - since the CsX flag was not set to boot out of bank1. That is why it was only doing 8k - it was the sector size of bank 1.

I assumed in crossworks that once you change the bank to program to 1, it would automatically change that bit for me, which it did not. It does have a javascript console where you can manually edit that (so you dont have to use CAPS), so once I got that flipped the programmer worked. The next battle was getting the bank switch working. Using the example code (remapping the banks then jumping to address 0x0) would hang the application. What I ended up doing was looking that the starting vectors were at address 0x40 on my code, so simply jumping to that address after remapping made the application run, which made me happy. So now I move onto my next battle -getting usb working under crossworks and all the fun that awaits me there 🙂 Cheers Daniel