|
My BDM and/or debugger sometimes sets the HCS12 in secure mode. I suspect that it has something to do with the target clock speed, sence the problem has only (yet) occured when I have the HCS12 to run in self clock mode. This do not happen very often, perhaps once per 50 downloads. Maybe it has something to do with data being corrupted in some way? I'm pretty sure that it isn't a hardware problem, sence I have had the same problem with different targets. It's not a big problem while developing, sence I can unsecure it when it happens. But I don't want the same to happen during production programming. So I wonder what might cause this problem? I'm using P&E Multilink BDM and Codewarrior on a HCS12DG256. Thanks, Daniel |
|
|
BDM sets secure mode?
Started by ●October 15, 2003
Reply by ●October 15, 20032003-10-15
|
Hi Daniel. It might happen due to a remaining pending interrupt just before programming, or more precisely, before erasing. The "erasing" algorythm currently performs a mass erasing, making the chip "secure" for a short time before it programs the security byte to "unsecure" mode. It is always welcome to reset the chip before going to NVMC Flash programming dialog, or to have a RESET command in "preload" command file of your project, before "flash erasing/programming" commands. You can always send me directly your project or a sample of your project that I could run to reproduce the problem. Regards, Gilles At 12:31 PM 10/15/2003, you wrote: >My BDM and/or debugger sometimes sets the HCS12 in secure mode. I >suspect that it has something to do with the target clock speed, >sence the problem has only (yet) occured when I have the HCS12 to run >in self clock mode. This do not happen very often, perhaps once per >50 downloads. > >Maybe it has something to do with data being corrupted in some way? >I'm pretty sure that it isn't a hardware problem, sence I have had >the same problem with different targets. > >It's not a big problem while developing, sence I can unsecure it when >it happens. But I don't want the same to happen during production >programming. So I wonder what might cause this problem? > >I'm using P&E Multilink BDM and Codewarrior on a HCS12DG256. >Thanks, >Daniel > >-------------------- > >">http://docs.yahoo.com/info/terms/ |
|
|
Reply by ●October 15, 20032003-10-15
|
Thanks for your answer. That might just be the problem. I'm not sure though, sence my preload.cmd file looks like: reset FLASH FLASH SELECT FLASH UNPROTECT FLASH ERASE 1-8 FLASH ARM I haven't changed the contents of the file sence it was generated by Codewarrior, besides adding which pages to erase. It seems a little bit strange that "reset" is typed in lower case... I don't know about those .cmd files, are they case-sensitive? (They are a pest btw, the debugger behaves as: 1. Detect that there is no contact with target, 2. Download the program what so ever :) ) But even if this file is ok, and do produce a reset, will the BDM be fast enough to erase the mcu before my program will run to where it enables interrupts? Unfortunatly I can't show you the program or any code from it, but it uses interrupts from timer, SPI, EEPROM, GP pins etc. --- In , Gilles Blanquin <gblanquin@m...> wrote: > > Hi Daniel. > > It might happen due to a remaining pending interrupt just before > programming, or more precisely, before erasing. > The "erasing" algorythm currently performs a mass erasing, making the chip > "secure" for a short time before it programs the security byte to > "unsecure" mode. > It is always welcome to reset the chip before going to NVMC Flash > programming dialog, or to have a RESET command in "preload" command file of > your project, before "flash erasing/programming" commands. > > You can always send me directly your project or a sample of your project > that I could run to reproduce the problem. > > Regards, > Gilles > > At 12:31 PM 10/15/2003, you wrote: > >My BDM and/or debugger sometimes sets the HCS12 in secure mode. I > >suspect that it has something to do with the target clock speed, > >sence the problem has only (yet) occured when I have the HCS12 to run > >in self clock mode. This do not happen very often, perhaps once per > >50 downloads. > > > >Maybe it has something to do with data being corrupted in some way? > >I'm pretty sure that it isn't a hardware problem, sence I have had > >the same problem with different targets. > > > >It's not a big problem while developing, sence I can unsecure it when > >it happens. But I don't want the same to happen during production > >programming. So I wonder what might cause this problem? > > > >I'm using P&E Multilink BDM and Codewarrior on a HCS12DG256. > > > > > >Thanks, > >Daniel > > > > > > > >-------------------- > > > > > > > >">http://docs.yahoo.com/info/terms/ |
Reply by ●October 15, 20032003-10-15
|
At 01:35 PM 10/15/2003, you wrote: >Thanks for your answer. >That might just be the problem. I'm not sure though, sence my >preload.cmd file looks like: > >reset >FLASH >FLASH SELECT >FLASH UNPROTECT >FLASH ERASE 1-8 >FLASH ARM > >I haven't changed the contents of the file sence it was generated by >Codewarrior, besides adding which pages to erase. It seems a little >bit strange that "reset" is typed in lower case... I don't know about >those .cmd files, are they case-sensitive? Daniel, commands are not case sensitive. >(They are a pest btw, the >debugger behaves as: 1. Detect that there is no contact with target, >2. Download the program what so ever :) ) We have changed all this in CodeWarrior V3.0 for HC(S)12. Commands files are no more used for programming. Flash programming is now a loading option ("Load Code to onchip Non Volatile Memory" option in Load dialog) release note extract: " The ICD12 Target Interface provides now a direct application loading and flashing feature within the application Load menu. It is no more required to play flash handling commands from preload and postload command files: The "Load Code to onchip Non Volatile Memory" option plays in background required flash commands. When this option is selected, it is possible to choose an "All Bytes" verification option which will compare (after programming) the original code with the device programmed code (read back). Note that this option performs a device "mass erase". For partial code loading, eeprom data loading, the Flash/NVMC dialog and regular flash commands are still 100% available to specify special/selective Non Volatile Memory operations to perform. " >But even if this file is ok, and do produce a reset, will the BDM be >fast enough to erase the mcu before my program will run to where it >enables interrupts? >Unfortunatly I can't show you the program or any code from it, but it >uses interrupts from timer, SPI, EEPROM, GP pins etc. I understand. As flash handling is performed like a regular assembler program execution, it is definitely sensitive to hardware events. Our flash drivers will be upgraded. I will keep you informed. Regards, Gilles >--- In , Gilles Blanquin <gblanquin@m...> wrote: > > > > Hi Daniel. > > > > It might happen due to a remaining pending interrupt just before > > programming, or more precisely, before erasing. > > The "erasing" algorythm currently performs a mass erasing, making >the chip > > "secure" for a short time before it programs the security byte to > > "unsecure" mode. > > It is always welcome to reset the chip before going to NVMC Flash > > programming dialog, or to have a RESET command in "preload" command >file of > > your project, before "flash erasing/programming" commands. > > > > You can always send me directly your project or a sample of your >project > > that I could run to reproduce the problem. > > > > Regards, > > Gilles > > > > > > > > At 12:31 PM 10/15/2003, you wrote: > > >My BDM and/or debugger sometimes sets the HCS12 in secure mode. I > > >suspect that it has something to do with the target clock speed, > > >sence the problem has only (yet) occured when I have the HCS12 to >run > > >in self clock mode. This do not happen very often, perhaps once per > > >50 downloads. > > > > > >Maybe it has something to do with data being corrupted in some way? > > >I'm pretty sure that it isn't a hardware problem, sence I have had > > >the same problem with different targets. > > > > > >It's not a big problem while developing, sence I can unsecure it >when > > >it happens. But I don't want the same to happen during production > > >programming. So I wonder what might cause this problem? > > > > > >I'm using P&E Multilink BDM and Codewarrior on a HCS12DG256. > > > > > > > > >Thanks, > > >Daniel > > > > > > > > > > > >-------------------- > > > > > > > > > > > >">http://docs.yahoo.com/info/terms/ > >-------------------- > >">http://docs.yahoo.com/info/terms/ |
