Hi Joe
That has helped since it gives me some more possibilities of comparing. In the dBUG instructions I read about the b,w,l but just couldn't work out the syntax since they are not mentioned in the help and the dot before them in the instructions looks like a bullet sign in a list so I never though about trying it in.
What I have learned is that the dBUG is intelligent when writing to FLASH locations. It programs changes (mm) in a word automatically as long as it can do this be programming bits to '0'.
This shows that the FLASH device supports programming individual bits in words to '0' which I find quite handly (several FLASH based devices only allow one write to a group which makes them somewhat tricky for some applications).
The fact that the dBUG does intelligent memory modifications doesn't allow the in-circuit FLASH sequences to be tested. So I still have to find out the solution using another method.
Do you know how the FLASHBAR register can be read with the dBUG?
I just found the "irmd" command which allows the registers in a peripheral block to be displayed - the contents CFM confirm my previous findings.
Since I am not getting anywhere using a BDM I will try to use the dBUG to debug a test program to see whether there is a difference with it.
Thanks
Mark
Joe
I have CW6.3!! Only installed it a few days ago. Have got my operating system running, the EMAC + EPHY operate and I can ping the board. The ftp and web server code is loaded but I have to get the FLASH programming running so that FTP server can use the internal file system to upload the web pages.
I could modify RAMBAR and FLASHBAR using the BDM but couldn't get rid of the write protect bit in FLASHBAR (although it is only an idea that it may be the real cause of my problems).
I just modified the project slightly so that I can load it to the board using dBUG. It runs and I get exactly the same phenomena - when the code tries to perform the flash programming sequence, the write to the FLASH address results in an access error (I can catch the interrupt). This means that it certainly has nothing to do with CW and the BDM.
dBUG, which is starting my code, can delete and program the FLASH. I conclude that there is still an initialisation which is missing somewhere. I have programmed the FLASH on the HCS12, using identical sequences and so was expecting the porting of the file system to be a piece of cake. But it seems as though the code is not even getting past the first write to FLASH to kick off the command sequence.
I took half a day to get the new EMAC driver running but have required nearly 2 days to get a three write FLASH programming instruction to work (and still counting). It is becoming a nightmare....I just can't find any references to having to prepare anything before starting the write.
My last resort will be to reverse engineer the assembler code in the dBUG routines (which are made of data constant arrays to be run from RAM - with no assembler source). It must be doing something which I haven't thought of yet.
Bang goes my weekend....
Cheers
Mark
Message Edited by mjbcswitzerland on 05-12-200602:30 PM