Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
|
Greetings everyone, We're developing a product based on the 9S12A128B. We've been developing using codewarrior(ugh) and the 9S12DP256 eval board from motorola. We just got our boards in and when I attempt to download code via the debugger/bdm, I get various 'Error while writing to...' (usually c000..c1ba) errors. I then tried creating a simple application using the 9S12Dx128 stationary, and it works fine as a RAM application, but has the same error when I try it as a FLASH(or banked flash) application. So does anyone know if the 9S12Dx128 stationary is setup to support the 9S12A128B? Inside the true-time debugger I verified the MCU type and speed settings are correct, and the CLKSW bit is set. I apologize for sending this to this list, but I can't find a newsserver that carries the codewarrior.* newsgroups, and I'm not sure metrowerks will help me now that my 90 days of support is up (and I don't feel like shelling out another 1k for another year). Thanks! Jason |
|
|
|
Jason, > I apologize for sending this to this list, but I can't find a newsserver > that carries the codewarrior.* newsgroups http://groups.google.com/groups?hl=de&lr=&ie=UTF-8&group=codewarrior.embedded The 9S12A128B needs different flash programming (other than the 9S12Dx), that's why you go the message from the debugger. Erich > -----Original Message----- > From: Gaiser, Jason [mailto:] > Sent: Tuesday, November 05, 2002 8:58 PM > To: > Subject: [68HC12] 9S12DP256 vs 9S12A128B > Greetings everyone, > > We're developing a product based on the 9S12A128B. We've been developing > using codewarrior(ugh) and the 9S12DP256 eval board from motorola. We just > got our boards in and when I attempt to download code via the debugger/bdm, > I get various 'Error while writing to...' (usually c000..c1ba) errors. > > I then tried creating a simple application using the 9S12Dx128 stationary, > and it works fine as a RAM application, but has the same error when I try it > as a FLASH(or banked flash) application. > > So does anyone know if the 9S12Dx128 stationary is setup to support the > 9S12A128B? Inside the true-time debugger I verified the MCU type and speed > settings are correct, and the CLKSW bit is set. > > I apologize for sending this to this list, but I can't find a newsserver > that carries the codewarrior.* newsgroups, and I'm not sure metrowerks will > help me now that my 90 days of support is up (and I don't feel like shelling > out another 1k for another year). > > Thanks! > Jason > -------------------------------------------------------- > To unsubscribe from this group, send an email to: > To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > |
|
|
|
Why would the A part need different Flash Programming than the DP part? It should be the same Flash technology in all 9S12 MCUs. To me it sounds like a stationary problem, which correlates to the .ini and .cmd files. Look at the .ini and .cmd files for the Fibo-FlashBanked example of the ICD12 examples. Make sure your actual project has similar .ini and .cmd files. --- In 68HC12@y..., "Erich Styger" <erich.styger@m...> wrote: > Jason, > > I apologize for sending this to this list, but I can't find a newsserver > > that carries the codewarrior.* newsgroups > http://groups.google.com/groups?hl=de&lr=&ie=UTF- 8&group=codewarrior.embedded > > The 9S12A128B needs different flash programming (other than the 9S12Dx), that's why > you go the message from the debugger. > > Erich > > > -----Original Message----- > > From: Gaiser, Jason [mailto:jason.gaiser@w...] > > Sent: Tuesday, November 05, 2002 8:58 PM > > To: 68hc12@y... > > Subject: [68HC12] 9S12DP256 vs 9S12A128B > > > > > > Greetings everyone, > > > > We're developing a product based on the 9S12A128B. We've been developing > > using codewarrior(ugh) and the 9S12DP256 eval board from motorola. We just > > got our boards in and when I attempt to download code via the debugger/bdm, > > I get various 'Error while writing to...' (usually c000..c1ba) errors. > > > > I then tried creating a simple application using the 9S12Dx128 stationary, > > and it works fine as a RAM application, but has the same error when I try it > > as a FLASH(or banked flash) application. > > > > So does anyone know if the 9S12Dx128 stationary is setup to support the > > 9S12A128B? Inside the true-time debugger I verified the MCU type and speed > > settings are correct, and the CLKSW bit is set. > > > > I apologize for sending this to this list, but I can't find a newsserver > > that carries the codewarrior.* newsgroups, and I'm not sure metrowerks will > > help me now that my 90 days of support is up (and I don't feel like shelling > > out another 1k for another year). > > > > Thanks! > > Jason > > > > > > -------------------------------------------------------- > > To unsubscribe from this group, send an email to: > > 68HC12-unsubscribe@y... > > > > To learn more about Motorola Microcontrollers, please visit > > http://www.motorola.com/mcu > > > > > > > > > |
|
Thanks a bunch for your help! I finally managed to get the flash programmed, but I'm not exactly sure why it works now. Basically I created a new project with the 9S12Dx128 stationary. I got the RAM to download ok, but the flash wasn't working. I was playing around with the debugger when I saw the "ICD-12->Flash..." menu entry. I went in there and unprotected and erased the modules on a whim, and then tried downloading again and it worked. Then I tried the same thing with our real project. It didn't seem to work so I started comparing files between the directories. I noticed the 'banked_flash.ini' files were different, with the working project omitting the CLKSW and clock speed settings (weird) and also the working copy had the following: BANKWINDOW0=BANKWINDOW PPAGE ON 0x8000..0xBFFF 0x30 256 BANKWINDOW1=BANKWINDOW DPAGE OFF 0x7000..0x7FFF 0x34 256 BANKWINDOW2=BANKWINDOW EPAGE OFF 0x400..0x7FF 0x36 256 Where the non-working project had: BANKWINDOW0=BANKWINDOW PPAGE ON 0x8000..0xBFFF BANKWINDOW1=BANKWINDOW DPAGE OFF 0x7000..0x7FFF BANKWINDOW2=BANKWINDOW EPAGE OFF 0x400..0x7FF Or something like that, since unfortunately I don't keep good notes. So once I basically copied the working .ini over the non-working one, I was able to download and debug the main project in flash. Its still pretty flakey, though, and 50% of the time I have to go into the "ICD-12->Flash..." and play around, or reset the part, but eventually it starts working again. Now the weird part - it stopped working again just now and I got it going again by setting clksw and redetecting the clock speed. Does anyone have a spare black cat for when it stops working next time? I didn't realize google had the codewarrior groups. I had checked on there before and didn't see them, so I just shelled out 5 bucks for a newsguy account. Thanks! Jason -----Original Message----- From: Erich Styger [mailto:] Sent: Wednesday, November 06, 2002 5:02 AM To: Subject: RE: [68HC12] 9S12DP256 vs 9S12A128B Jason, > I apologize for sending this to this list, but I can't find a newsserver > that carries the codewarrior.* newsgroups http://groups.google.com/groups?hl=de&lr=&ie=UTF-8&group=codewarrior.embedde d The 9S12A128B needs different flash programming (other than the 9S12Dx), that's why you go the message from the debugger. Erich |
|
|
|
Hi Jason. BANKWINDOW variables are set up within the "Set Banks.../Banked Memory Location" dialog. Indeed, the A128 has program banks/pages that are usually "ready setup" in derivative specific examples/stationery. Also it is a very normal way in our debugger to go through the "Flash../Non Volatile Memory" dialog to program the onchip flash. Note that as long as the Flash dialog is not opened or as long as no "FLASH" command is executed, the debugger is NOT aware of Flash memory ranges. Once the FLASH command is executed or dialog opened, the NVM manager will filter all debugger addresses. => not possible to write directly to these areas. You can automate application "flash" loading this way (no need to go always go thru the dialog). In your preload command file, write the following commands: // reset the target board RESET // start NVM manager FLASH // select the flash modules FLASH SELECT // erase all the flash modules FLASH ERASE // arm the flash for programming FLASH ARM In your postload command file, write the following commands: // disarm the flash modules FLASH DISARM // unselect the flash modules FLASH UNSELECT // reset the target board RESET Regards, Gilles At 07:25 PM 11/6/2002, you wrote: >Thanks a bunch for your help! > >I finally managed to get the flash programmed, but I'm not exactly sure why >it works now. Basically I created a new project with the 9S12Dx128 >stationary. I got the RAM to download ok, but the flash wasn't working. I >was playing around with the debugger when I saw the "ICD-12->Flash..." menu >entry. I went in there and unprotected and erased the modules on a whim, >and then tried downloading again and it worked. > >Then I tried the same thing with our real project. It didn't seem to work >so I started comparing files between the directories. I noticed the >'banked_flash.ini' files were different, with the working project omitting >the CLKSW and clock speed settings (weird) and also the working copy had the >following: > >BANKWINDOW0=BANKWINDOW PPAGE ON 0x8000..0xBFFF 0x30 256 >BANKWINDOW1=BANKWINDOW DPAGE OFF 0x7000..0x7FFF 0x34 256 >BANKWINDOW2=BANKWINDOW EPAGE OFF 0x400..0x7FF 0x36 256 > >Where the non-working project had: >BANKWINDOW0=BANKWINDOW PPAGE ON 0x8000..0xBFFF >BANKWINDOW1=BANKWINDOW DPAGE OFF 0x7000..0x7FFF >BANKWINDOW2=BANKWINDOW EPAGE OFF 0x400..0x7FF > >Or something like that, since unfortunately I don't keep good notes. > >So once I basically copied the working .ini over the non-working one, I was >able to download and debug the main project in flash. Its still pretty >flakey, though, and 50% of the time I have to go into the "ICD-12->Flash..." >and play around, or reset the part, but eventually it starts working again. > >Now the weird part - it stopped working again just now and I got it going >again by setting clksw and redetecting the clock speed. Does anyone have a >spare black cat for when it stops working next time? > >I didn't realize google had the codewarrior groups. I had checked on there >before and didn't see them, so I just shelled out 5 bucks for a newsguy >account. > >Thanks! >Jason >-----Original Message----- >From: Erich Styger [mailto:] >Sent: Wednesday, November 06, 2002 5:02 AM >To: >Subject: RE: [68HC12] 9S12DP256 vs 9S12A128B >Jason, > > I apologize for sending this to this list, but I can't find a newsserver > > that carries the codewarrior.* newsgroups >http://groups.google.com/groups?hl=de&lr=&ie=UTF-8&group=codewarrior.embedde >d > >The 9S12A128B needs different flash programming (other than the 9S12Dx), >that's why >you go the message from the debugger. > >Erich > >-------------------------------------------------------- >To unsubscribe from this group, send an email to: >To learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu [Non-text portions of this message have been removed] |
|
> So once I basically copied the working .ini over the non-working > one, I was > able to download and debug the main project in flash. Its still pretty > flakey, though, and 50% of the time I have to go into the > "ICD-12->Flash..." > and play around, or reset the part, but eventually it starts > working again. > > Now the weird part - it stopped working again just now and I got it going > again by setting clksw and redetecting the clock speed. Does > anyone have a > spare black cat for when it stops working next time? > Unfortunately, this seems to be a problem in the current version of CodeWarrior+ICD-12. I have to go through several minutes of gymnastics every day in order to be able to use the device. It keeps setting itself back to simulator, and trying to download to the wrong location. Lots of retrys (the cancel button doesn't work) and resetting of values later, it finally starts working, and will often work for several hours unless some as yet undefined problem occurs. I have reported this to Metrowerks several times, but they have not come up with any sort of fix or explanation. It is definitely NOT a function of the INI files getting corrupted, the problem exists somewhere in the program itself. If you find a black cat or rubber chicken that works, please let me know. Regards, Paul Johnson |
|
|
|
Paul and all, Commercial debuggers with all the needed features to debug an HCS12 applications are available in the market. Nohau for example has a BDM debugger with C/Assembly level support for all HCS12 parts sells for 1990 $US. It does not limit the maximum HCS12 speed, and does not work only 50% of the time. For higher end applications that need higher debugging power, full-featured emulator with an option of trace and triggers is also available from Nohau. Other emulator vendors also exist. I recently see many problems exist with very low cost BDM tools. These problems cost in valuable engineering time lost, which directly translate to money. So even if your budget is tight, and you choose to use a BDM tool, do yourself a favour and buy a good BDM, for around 2000 $US, from a reputable emulator maker. It will save you several times the cost, by not wasting your valuable engineering time to chase emulator problems. Doron Nohau Corporation HC12/HCS12 In-Circuit Emulators www.nohau.com > > So once I basically copied the working .ini over the non-working > > one, I was > > able to download and debug the main project in flash. Its still pretty > > flakey, though, and 50% of the time I have to go into the > > "ICD-12->Flash..." > > and play around, or reset the part, but eventually it starts > > working again. > > > > Now the weird part - it stopped working again just now and I got it going > > again by setting clksw and redetecting the clock speed. Does > > anyone have a > > spare black cat for when it stops working next time? > > >Unfortunately, this seems to be a problem in the current version of >CodeWarrior+ICD-12. I have to go through several minutes of gymnastics >every day in order to be able to use the device. It keeps setting itself >back to simulator, and trying to download to the wrong location. Lots of >retrys (the cancel button doesn't work) and resetting of values later, it >finally starts working, and will often work for several hours unless some as >yet undefined problem occurs. > >I have reported this to Metrowerks several times, but they have not come up >with any sort of fix or explanation. It is definitely NOT a function of the >INI files getting corrupted, the problem exists somewhere in the program >itself. > >If you find a black cat or rubber chicken that works, please let me know. > >Regards, > >Paul Johnson [Non-text portions of this message have been removed] |
|
Hi Paul. I will contact you directly "off list" to try to fix this problem. I cannot reproduce this problem with the current CodeWarrior for HC12 (version 1.2 / MOT v1.2). Regards, Gilles At 08:06 PM 11/27/2002, you wrote: > > So once I basically copied the working .ini over the non-working > > one, I was > > able to download and debug the main project in flash. Its still pretty > > flakey, though, and 50% of the time I have to go into the > > "ICD-12->Flash..." > > and play around, or reset the part, but eventually it starts > > working again. > > > > Now the weird part - it stopped working again just now and I got it going > > again by setting clksw and redetecting the clock speed. Does > > anyone have a > > spare black cat for when it stops working next time? > > >Unfortunately, this seems to be a problem in the current version of >CodeWarrior+ICD-12. I have to go through several minutes of gymnastics >every day in order to be able to use the device. It keeps setting itself >back to simulator, and trying to download to the wrong location. Lots of >retrys (the cancel button doesn't work) and resetting of values later, it >finally starts working, and will often work for several hours unless some as >yet undefined problem occurs. > >I have reported this to Metrowerks several times, but they have not come up >with any sort of fix or explanation. It is definitely NOT a function of the >INI files getting corrupted, the problem exists somewhere in the program >itself. > >If you find a black cat or rubber chicken that works, please let me know. > >Regards, > >Paul Johnson > >-------------------------------------------------------- >To unsubscribe from this group, send an email to: >To learn more about Motorola Microcontrollers, please visit >http://www.motorola.com/mcu |