USB-BDM issue with Flash on 9S12

[mke_et]

I'm using the USB-BDM pod to develope on a 9S12 platform and have an interesting error.

Sometimes my program will 'hang' when I try to update the flash data from within my program.  (My program uses one of the flash pages as a data area).

Now, I'm not 100% sure, but I'm PRETTY sure this happens AFTER I program the flash with new code, and when I hit <F5> to execute, I get an illegal BP or some other kind of error.  I can usually just ICD-12 then reset and then Run restart and the code executes fine, inializing the board and running.

Until I get to where I try to write some flash data

Now, I didn't use my old LPT based BDM-MultiLink that much before I changed over to the USB-BDM pod, but it seems to me the USB-BDM pod has some 'issues'. 

Anyone else seeing these kinds of things?

Mike Yetsko

[EMontanez]

Just read a few more threads and it looks like you had a similar thread already posted where you got some help and resolved this issue. :smileyhappy:

[mke_et]

99% of my flash issues are resolved.

However, I STILL see the error with the USB-BDM, and if I get that then I'm 99% certain a failure trying to write to the flash will occur.  If I just exit the debugger, and power cycle the target platform, it will run just fine, updating the flash as it should.  That right there shows me the problem does not appear to be in my routines. 

If I am programming the code space with the BDM by hitting F5 from CW, the error seems to be the USB-BDM chokes AFTER it thinks it programs the part and I then hit F5 from the debug screen to start execution.  It will not 'start' the CPU correctly.  Once that happens, if I use the reset from the debug screen to the BDM and restart, the code will start and run, UP TO the point where it tries to write to flash, and then it hangs.

If hitting F5 from the debug screen starts the CPU correctly, then the CPU will continue to run and the flash can be programmed correctly.

The 'break point' is what happens AFTER the CPU is programmed and BEFORE

the F5 key is hit to 'run'.  If it gets by that then it runs fine.  If I have to 'kludge' past that with manual intervention, then it will fail later.  If I have to kludge past that and I do it by a power-cycle of the target (and blow off the BDM and debug capability) then it will run fine.

Mike

[EMontanez]

Mike,

Your last post was kind of confusing to follow, but I'll take another stab at what might be occuring.

Assuming that your programming routines work fine in normal user modes (without BDM pod connected following a device reset). The case may be that in special modes (BDM active, when you have CW debugger open and the device is waiting for a "go" command) that your programming routines choke when you hit F5 because you have a memory window open in the CW debugger. I have seen some cases where you get a memory violation because the user code is writing to flash memory in the same physical flash block that the debugger memory window is refreshing, therefore performing an illegal read-while-write in the same physical flash block. Try closing the memory windows and see if you can run your code within the debugger without it crashing.

Ok, this might be a stab in the dark, but you never know...its happened before.

Message Edited by EMontanez on 03-08-2006 01:39 PM

[EMontanez]

Mike,

Is the program that executes the data writes in flash executing out of flash memory as well?

I can see you having issues reading out of flash (program executing) while writing to flash if you are using memory in the same flash block.

Overall, from reading your post I cannot pin point why the USB BDM would be the culprit. I would suggest double checking that you are choosing flash memory to write your data in another flash block than the one executing the writes.