repost : reprogramming flash memory problem

Pat,

I remember its been quite a while since you started with this problem, would you be able to zip and attach a simple project which tries to do the below? is this f28M35x or M36xand which revision are you looking at? I'll try to reproduce the problem if you already have a project.

...

Pat Harris said:

This would be a matter of simply reading flash memory from 0x200000 to say 0x220000 , programming it to a high memory location, and then writing it back to 0x200000, and halting to allow the wdt to fire. Can this actually be done? I've put everything that appears to be involved in the operation into ramfuncs, but still I cannot get it to work,

Best Regards

Santosh

Santosh,

Thanks for your response. I am running the f28m35h52c1, rev B (YFB - 34C9VCW). I have modified your example from the V201, dual, flash_prog. I placed all code into the flash_programming_m3.c file. This should cover the core of the matter. I read all memory from 0x200000 to 0x220000 and program it into the region from 0x230000 to 0x250000, then attempt to erase and reprogram eveerything back at the 0x200000 region.

The erase of the lower memory is the point of failure as I can program everything at 0x230000 fine.

Thanks,

Pat

0647.flash_programming_m3.zip

Pat,

thanks. Could you also send me the MAP file and the linker command file you got when you built the project.

Best Regards

santosh

Pat,

reviewing your code, I have below questions.

1.>  what is the value of Bzero_SectorN_start - is it after the CSM password location for Z1? The password locations are linked properly with all 0xFFFFs ?

2.> The RAM funcs you put for ex: FlashWrite you think are executing from RAM, but this function internally calls other funcs like Fapi_* ; where are these functions placed. (send me your map file to look at this).

2.> Where is this function located? Why isn't it in RAMfuncs?
Example_CallFlashAPI

your code execution is as below

main() 

           -> Example_CallFlashAPI()

                        -> DLoadInit

                        -> DLoadCode....call to RAM func from flash and return to flash 

                        -> XferInit() ....call to RAM func from flash and return to flash {N.M,L,K,J erased}

                       ->move_to_lower...call to RAM func from flash and return to flash [is this function in flash valid or erased]

                       ->FlashLeavePump (this is not in RAM funcs, so executing from flash)

                       ->Example Done (again from RAM, but the call is happining from flash)

in 3.> above at the RED highlighted line where is XferInit returning to? I mean which flash sector is that flash sector erased?

Best Regards

Santosh

2577.flash_programming_m3_FLASH.zip

2677.flash_programming_m3.zip

Santosh,

It was not clear to me if adding

Example_CallFlashAPI() to ramfuncs made any difference, so I added blinky to the end of the program in Example_Done(). When I skip Example_CallFlash(), blinky occurs. Adding it causes a hangup and multiple resets.

0172.flash_programming_m3 (3).zip

Thanks,

Pat

Pat,

got this crosschecked with the flash api expert, I think we found the problem. The function Fapi_serviceWatchdogTimer is called during flash operations is linked to flash as this function is out of the API library and is coming from the C source Fapi_UserDefinedFunctions.c file. Please place this functions also in the RAMFUNCS using hte #PRAGMA and try it out.

Also the Example_CallFlashAPI should be placed in RAMFUNCS as well instead of flash because after first copy of LOW to HIGH and after erase of LOW MEM the program control branches back to this function thinking that it is still in flash but it got erased now.

Hope it helps, let us know.

Best Regards

Santosh

Santosh,

Looks promising ...

Well, I thought that 0x200000 might have reprogrammed correctly, but I'm not sure. My breakpoints don't appear to work as I try to step through the code.

Blinky doesn't run either. Were you able to get it to run? .. stop at breakpoints? .. observe that blinky is actually running?

Pat

Inspect your map file again to see if there are other fapi_* functions mapped to flash that might get execute after the sectors are erased but before the copy happens. Thats the crux of the problem, there is one other fapi routine like the the watchdog routine thats in flash as well.

I haven't tried to run this today as I was on a loaner laptop and don't have my environment set up yet, I'll see what I can do tomorrow.

Send me the updated map file if it doesn't work after you move all the fapi functions to ram.

Best regards

Santosh

I made the changes you suggested as well as adding the utilities changes

2364.flash_programming_m3_FLASH (2).zip

8510.Fapi_UserDefinedFunctions.zip

4571.flash_programming_m3 (4).zip

5415.flash.zip

Thanks,

Pat

and the map file, sorry.

4744.flash_programming_m3 (2).zip

in the map file you sent, I still see the below functions in flash 

00205011 FlashGainPump
0020501f FlashLeavePump

can you recheck?

Best regards

santosh

Santosh,

I can't seem to get them placed there even if add the #pragmas. Here's the latest:

2330.flash_programming_m3 (3).zip

0434.flash_programming_m3 (5).zip

4670.flash_programming_m3_FLASH (3).zip

Pat

Pat,

I'm unable to compile the example project with your sources because it is missing some includes (the pinout include). Would you be able to zip the entire example project you are getting to RUN and send it to me.

Best Regards

Santosh

That file is in the V201 mware. I wanted to send you the entire V201 folder, but there doesn't appear to be any way to send folders through this tool, only files. I am using compiler arm_5.1_1. Everything came from the V201 folder.

6242.set_pinout_f28m35x.zip

7651.flash_proj.zip

.

Pat,

I couldn't try building this today, can you try putting the entire driverlib in RAMfuncs just like flash api lib and see if it works out then we can optimize it further.

one more thing I wanted to ask is why you aren't able to put break points, you would be using HW breakpoints for flash but for RAM its SW brak points. Now the main example flashAPI function is in RAM you should be able to put break points and see after calling which function the program goes to weeds. Did you try that? we are very close it is defnitely failing after you erase the LOW MEM (after copying it to HIGHMEM), so once that erase of LOWMEM function returns or completes see where it is going.

I wish we could to a webex meeting and have a call. Do you have an FAE whom you are working with, we could contact them to set this debug session up. This problem has been dragging for a while and I see no reason why your use case wont work.

Best Regards

santosh

Santosh,

Here's the latest files. I added the library. No change. It appears from the debug breakpoints that the transfer to ram never occurred??

1220.flash_programming_m3 (6).zip

2543.flash_programming_m3_FLASH (4).zip

6710.flash_programming_m3 (4).zip

And here are a couple screen shots. Both the disassembly and the memory views show ram to be all zeros.

2450.test flashprog example 1.docx

Thanks,

Pat

Santosh,

As far as Webex, I could sign up for the service. Would the free version be sufficient, or would I need to purchase more capability?

Pat

Pat,

I'm not sure about the limitations of free webex, where are you located? Anyways I looked at your latest snapshots and the code and have below questions, lets try to debug this a bit further with snapshots.

Why is your RAM all zeroes? Did you check if your memcopy of RAM funcs is happening properly? are you able to write anything to RAM from debugger memory window?

 Best Regards

Santosh

Pat,

Brett mentioned that we could try setting up a webex session with the free version. what is your official mail ID and time zone, I will try to set up a webex meeting and conference call and send you the details.

Best Regards

Santosh

Santosh,

me2@meetechnology.com in the US, central time zone

I am sending the latest set of files:

3782.flash_programming_m3_FLASH (5).zip

4075.flash_programming_m3 (7).zip

7331.flash_programming_m3 (5).zip

The source file and .cmd file are at a state where I had tried to remove all flash erase for the transfer to lower memory except the upper location 0x220000. Erasing more that this would result in continuous resets of the code when run using CCS debug. I then added back into the ramfuncs, the driverlib.lib using the .cmd file. This then also caused repeated resets. By bypassing the erase functions and commenting out the attempt to transfer the code as well as the inclusion of the driverlib in the .cmd file, the blinky function will run. However, I cannot erase lower memory. I cannot reprogram code (just to reiterate).

I am trying to isolate the driverlib function that may be causing the hangup. Perhaps you could help with this if you can run the example there?

Thanks,

Pat

we had a productive debug session, the issue is traced to two things below.

1.> SP is over writing RAMFUNCS, somewhere during the program execution. We moved RAMFUNCS to a separate memory section.

2.. un-initialized local variable which is indexed in an array is causing the data writes to the array go bizarre.

Best Regards

Santosh