Sign in
Search 68hc12
Subscribe to 68hc12
68hc12 by Keywords
68HC1 | 812A4 | 9S12DP256 | Bootloader | CodeWarrior | D60A | Debugger | DP256 | ECT | EEPROM | EVB | Flash | HC1 | HCS12 | I2C | IAR | ICC1 | Interrupts | LCD | M68KIT912DP256 | MC9S12DP256 | MC9S12DP256B | Metrowerks | Motor | MSCAN | Multilink | PLL | Quadrature | SDI | SPI | Transceiver | XFC
Ads
Discussion Groups
See Also
Discussion Groups | 68HC12 | Metrowerks Ver3.1 & DBug12 Flash Programming
Join our technical discussions about Freescale Microcontrollers: M68HC12. (Freescale Semiconductor is a Subsidiary of Motorola).
Metrowerks Ver3.1 & DBug12 Flash Programming - hebs_s - Jul 26 7:56:00 2005
Hi,
All!
I am using Debug12 for Flash programming of target borad in POD
using Evaluation board.It is possible to program &erase target flash
using HyperTerminal as Terminal Emulation program.
Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the Flash
but unable to do so.It is giving an error.
Is this the limitation of Metrowerks? Request to answer if you know
exactly the possible causes.
Pl confirm.Thanks in anticipation.
regards,
hebs
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
All!
I am using Debug12 for Flash programming of target borad in POD
using Evaluation board.It is possible to program &erase target flash
using HyperTerminal as Terminal Emulation program.
Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the Flash
but unable to do so.It is giving an error.
Is this the limitation of Metrowerks? Request to answer if you know
exactly the possible causes.
Pl confirm.Thanks in anticipation.
regards,
hebs
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: MCUID Frustration... - Jonathan Masters - Jul 26 8:43:00 2005
Evening all.
I have just spent the past hour trying to get a prototype with a
9S12DG256C soldered on working. The software was written and tested with
a DP256 EVB (with the "C" 2KX79 mask set chip inserted). With the new
board I have a specific problem:
i) With the Metrowerks/ICD12 debugger that is coming up
with strange messages about there being no memory between 0x400 and
0x600 (EEPROM on a DP256).
ii) If I read the INITRM register on the DP256
immediately after reset, I get 0x01 - placing the EEPROM from 0x0000 to
0x0fff and enabled.
iii) If I read the INITRM register on the DG256C I get 0x40
- placing the EEPROM from 0x4000 to 0x4fff and disabled.
Search the Freescale web site for 9S12DG256C and get no results. Take
the "C" suffix off and get results for the 9S12DG256B. (This yields no
errata (hi Oliver ;)) for the 2KX79 mask set)
Clearly I haven't understood some difference between the DP and DG
parts. Yet extensive searching of the "modular" data sheets has found no
occurrences of "MCUID" which I might use to check that the debugger is
using the correct FPP files. Nor since the DG data is the DP data can I
find any reason why EEPROM is being mapped at 0x4000 instead of 0x0400.
I could assume that Freescale's documentation (while lacking and leaving
me without confidence (hi Oliver;)) is not incorrect. This takes me back
to the possibility I am having trouble driving the Metrowerks debugger
(but I won't even begin to offer my opinion of the Metrowerks help
system).
Having had a whinge and got my frustrations out, can anyone suggest how
I might correctly tell the debugger that the EEPROM at 0x400 in the ELF
file really should be programmed at 0x400?
Jonathan. [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
I have just spent the past hour trying to get a prototype with a
9S12DG256C soldered on working. The software was written and tested with
a DP256 EVB (with the "C" 2KX79 mask set chip inserted). With the new
board I have a specific problem:
i) With the Metrowerks/ICD12 debugger that is coming up
with strange messages about there being no memory between 0x400 and
0x600 (EEPROM on a DP256).
ii) If I read the INITRM register on the DP256
immediately after reset, I get 0x01 - placing the EEPROM from 0x0000 to
0x0fff and enabled.
iii) If I read the INITRM register on the DG256C I get 0x40
- placing the EEPROM from 0x4000 to 0x4fff and disabled.
Search the Freescale web site for 9S12DG256C and get no results. Take
the "C" suffix off and get results for the 9S12DG256B. (This yields no
errata (hi Oliver ;)) for the 2KX79 mask set)
Clearly I haven't understood some difference between the DP and DG
parts. Yet extensive searching of the "modular" data sheets has found no
occurrences of "MCUID" which I might use to check that the debugger is
using the correct FPP files. Nor since the DG data is the DP data can I
find any reason why EEPROM is being mapped at 0x4000 instead of 0x0400.
I could assume that Freescale's documentation (while lacking and leaving
me without confidence (hi Oliver;)) is not incorrect. This takes me back
to the possibility I am having trouble driving the Metrowerks debugger
(but I won't even begin to offer my opinion of the Metrowerks help
system).
Having had a whinge and got my frustrations out, can anyone suggest how
I might correctly tell the debugger that the EEPROM at 0x400 in the ELF
file really should be programmed at 0x400?
Jonathan. [Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks Ver3.1 & DBug12 Flash Programming - Gilles Blanquin - Jul 27 9:17:00 2005
Hi.
The D-bug12 is a Legacy host target interface provided "as is" for backward
compatibility purposes in Metrowerks Ver 3.0 & Ver 3.1.
Also the flash programming support as never been implemented in the D-bug12
Target Interface, when the target board is used in POD mode.
Regards,
Gilles At 01:56 PM 7/26/2005, you wrote:
>Hi,
>
>All!
>
>I am using Debug12 for Flash programming of target borad in POD
>using Evaluation board.It is possible to program &erase target flash
>using HyperTerminal as Terminal Emulation program.
>
>Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the Flash
>but unable to do so.It is giving an error.
>
>Is this the limitation of Metrowerks? Request to answer if you know
>exactly the possible causes.
>
>Pl confirm.Thanks in anticipation.
>
>regards,
>hebs >
>Yahoo! Groups Links
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: MCUID Frustration... - Gilles Blanquin - Jul 27 9:26:00 2005
Hi Jonathan.
Due to onchip resources overlap, the flash programming driver might
relocate the eeprom to a different place to be able to program the eeprom.
Before trying to isolate the problem, please tell me which version of
CodeWarrior you use. Indeed, as everything, drivers are from time to time
upgraded, and I need to check this issue on the same debugger.
Regards,
Gilles At 02:43 PM 7/26/2005, you wrote:
>Evening all.
>
>I have just spent the past hour trying to get a prototype with a
>9S12DG256C soldered on working. The software was written and tested with
>a DP256 EVB (with the "C" 2KX79 mask set chip inserted). With the new
>board I have a specific problem:
>
>i) With the Metrowerks/ICD12 debugger that is coming up
>with strange messages about there being no memory between 0x400 and
>0x600 (EEPROM on a DP256).
>ii) If I read the INITRM register on the DP256
>immediately after reset, I get 0x01 - placing the EEPROM from 0x0000 to
>0x0fff and enabled.
>iii) If I read the INITRM register on the DG256C I get 0x40
>- placing the EEPROM from 0x4000 to 0x4fff and disabled.
>
>Search the Freescale web site for 9S12DG256C and get no results. Take
>the "C" suffix off and get results for the 9S12DG256B. (This yields no
>errata (hi Oliver ;)) for the 2KX79 mask set)
>
>Clearly I haven't understood some difference between the DP and DG
>parts. Yet extensive searching of the "modular" data sheets has found no
>occurrences of "MCUID" which I might use to check that the debugger is
>using the correct FPP files. Nor since the DG data is the DP data can I
>find any reason why EEPROM is being mapped at 0x4000 instead of 0x0400.
>
>I could assume that Freescale's documentation (while lacking and leaving
>me without confidence (hi Oliver;)) is not incorrect. This takes me back
>to the possibility I am having trouble driving the Metrowerks debugger
>(but I won't even begin to offer my opinion of the Metrowerks help
>system).
>
>Having had a whinge and got my frustrations out, can anyone suggest how
>I might correctly tell the debugger that the EEPROM at 0x400 in the ELF
>file really should be programmed at 0x400?
>
>Jonathan. >[Non-text portions of this message have been removed] >
>
>Yahoo! Groups Links
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: MCUID Frustration... - Jonathan Masters - Jul 27 17:28:00 2005
Gilles,
Thanks for your reply. I have done some more work on the problem with a
lot less fatigue clouding my judgement.
I am using CW3.1 with Upgrade V1.3 for USB. I am not using the USB (the
driver has broken and I haven't had time to figure out how to fix it). I
am using the LPT version.
My binary loads a Vector table into EEPROM at 0x400. The main program is
located unbanked FLASH spaces at 0x4000 and 0xC000.
To break the problem down, I have another EVB to which I have fitted a
DG256 chip. This loads perfectly. Naturally this led me to believe that
I have a hardware problem on my first board. I have checked each pin
between the EVB connection and my board connection and can't find any
difference - except that the EVB clock is 16MHz external and the board
clock is 8MHz crystal.
Long story short - It appeared that the EEPROM or FLASH was protected
and was upsetting the burner on load. I started the debugger without
loading the application. I then unsecured the chip - now it loads
normally. The problem is how I got into this situation in the first
place - this was a new chip and the board had no hardware faults - I
suspect the chip was not erased out of the packet.
My final question is - where does one find a list of MCUIDs. A search on
the Freescale website yields nothing useful, there is nothing in the
device documents save the PARTID and MEMSIZ registers which don't yield
values like the MCUIDs. What am I missing?
Thanks,
Jonathan. -----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Gilles Blanquin
Sent: Wednesday, 27 July 2005 11:27 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] MCUID Frustration... Hi Jonathan.
Due to onchip resources overlap, the flash programming driver might
relocate the eeprom to a different place to be able to program the
eeprom.
Before trying to isolate the problem, please tell me which version of
CodeWarrior you use. Indeed, as everything, drivers are from time to
time
upgraded, and I need to check this issue on the same debugger.
Regards,
Gilles At 02:43 PM 7/26/2005, you wrote:
>Evening all.
>
>I have just spent the past hour trying to get a prototype with a
>9S12DG256C soldered on working. The software was written and tested
with
>a DP256 EVB (with the "C" 2KX79 mask set chip inserted). With the new
>board I have a specific problem:
>
>i) With the Metrowerks/ICD12 debugger that is coming up
>with strange messages about there being no memory between 0x400 and
>0x600 (EEPROM on a DP256).
>ii) If I read the INITRM register on the DP256
>immediately after reset, I get 0x01 - placing the EEPROM from 0x0000 to
>0x0fff and enabled.
>iii) If I read the INITRM register on the DG256C I get
0x40
>- placing the EEPROM from 0x4000 to 0x4fff and disabled.
>
>Search the Freescale web site for 9S12DG256C and get no results. Take
>the "C" suffix off and get results for the 9S12DG256B. (This yields no
>errata (hi Oliver ;)) for the 2KX79 mask set)
>
>Clearly I haven't understood some difference between the DP and DG
>parts. Yet extensive searching of the "modular" data sheets has found
no
>occurrences of "MCUID" which I might use to check that the debugger is
>using the correct FPP files. Nor since the DG data is the DP data can I
>find any reason why EEPROM is being mapped at 0x4000 instead of 0x0400.
>
>I could assume that Freescale's documentation (while lacking and
leaving
>me without confidence (hi Oliver;)) is not incorrect. This takes me
back
>to the possibility I am having trouble driving the Metrowerks debugger
>(but I won't even begin to offer my opinion of the Metrowerks help
>system).
>
>Having had a whinge and got my frustrations out, can anyone suggest how
>I might correctly tell the debugger that the EEPROM at 0x400 in the ELF
>file really should be programmed at 0x400?
>
>Jonathan. >[Non-text portions of this message have been removed] >
>
>> Terms of Service.
_____
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Thanks for your reply. I have done some more work on the problem with a
lot less fatigue clouding my judgement.
I am using CW3.1 with Upgrade V1.3 for USB. I am not using the USB (the
driver has broken and I haven't had time to figure out how to fix it). I
am using the LPT version.
My binary loads a Vector table into EEPROM at 0x400. The main program is
located unbanked FLASH spaces at 0x4000 and 0xC000.
To break the problem down, I have another EVB to which I have fitted a
DG256 chip. This loads perfectly. Naturally this led me to believe that
I have a hardware problem on my first board. I have checked each pin
between the EVB connection and my board connection and can't find any
difference - except that the EVB clock is 16MHz external and the board
clock is 8MHz crystal.
Long story short - It appeared that the EEPROM or FLASH was protected
and was upsetting the burner on load. I started the debugger without
loading the application. I then unsecured the chip - now it loads
normally. The problem is how I got into this situation in the first
place - this was a new chip and the board had no hardware faults - I
suspect the chip was not erased out of the packet.
My final question is - where does one find a list of MCUIDs. A search on
the Freescale website yields nothing useful, there is nothing in the
device documents save the PARTID and MEMSIZ registers which don't yield
values like the MCUIDs. What am I missing?
Thanks,
Jonathan. -----Original Message-----
From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
Of Gilles Blanquin
Sent: Wednesday, 27 July 2005 11:27 PM
To: 68HC12@68HC...
Subject: RE: [68HC12] MCUID Frustration... Hi Jonathan.
Due to onchip resources overlap, the flash programming driver might
relocate the eeprom to a different place to be able to program the
eeprom.
Before trying to isolate the problem, please tell me which version of
CodeWarrior you use. Indeed, as everything, drivers are from time to
time
upgraded, and I need to check this issue on the same debugger.
Regards,
Gilles At 02:43 PM 7/26/2005, you wrote:
>Evening all.
>
>I have just spent the past hour trying to get a prototype with a
>9S12DG256C soldered on working. The software was written and tested
with
>a DP256 EVB (with the "C" 2KX79 mask set chip inserted). With the new
>board I have a specific problem:
>
>i) With the Metrowerks/ICD12 debugger that is coming up
>with strange messages about there being no memory between 0x400 and
>0x600 (EEPROM on a DP256).
>ii) If I read the INITRM register on the DP256
>immediately after reset, I get 0x01 - placing the EEPROM from 0x0000 to
>0x0fff and enabled.
>iii) If I read the INITRM register on the DG256C I get
0x40
>- placing the EEPROM from 0x4000 to 0x4fff and disabled.
>
>Search the Freescale web site for 9S12DG256C and get no results. Take
>the "C" suffix off and get results for the 9S12DG256B. (This yields no
>errata (hi Oliver ;)) for the 2KX79 mask set)
>
>Clearly I haven't understood some difference between the DP and DG
>parts. Yet extensive searching of the "modular" data sheets has found
no
>occurrences of "MCUID" which I might use to check that the debugger is
>using the correct FPP files. Nor since the DG data is the DP data can I
>find any reason why EEPROM is being mapped at 0x4000 instead of 0x0400.
>
>I could assume that Freescale's documentation (while lacking and
leaving
>me without confidence (hi Oliver;)) is not incorrect. This takes me
back
>to the possibility I am having trouble driving the Metrowerks debugger
>(but I won't even begin to offer my opinion of the Metrowerks help
>system).
>
>Having had a whinge and got my frustrations out, can anyone suggest how
>I might correctly tell the debugger that the EEPROM at 0x400 in the ELF
>file really should be programmed at 0x400?
>
>Jonathan. >[Non-text portions of this message have been removed] >
>
>> Terms of Service.
_____
[Non-text portions of this message have been removed]
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
RE: MCUID Frustration... - Gilles Blanquin - Jul 28 9:10:00 2005
Hi Jonathan.
The MCUIDs list "belongs" for the HC(S)12 Family to the CodeWarrior HI-WAVE
debugger.
This list makes the link between part names and internal files/drivers to
use for a part. The list is stored in the "hc12.ini" file in "prog" folder.
The MCUID is a Legacy list defined years ago by Motorola for MMDS/MMEVS
emulators (HC05 and HC08 families), which actually return an MCUID
corresponding to the plugged Emulation Module.
This list got derived to HC(S)12 family for Motorola SDI cables support,
cables running with the same server/driver as the one used for MMDS/MMEVS.
If some MCUID information still appears in the debugger, this will in
feature be removed (let say, be transparent to the user), as Legacy cables
like SDI cannot stand latest silicons anyway.
Regards,
Gilles
At 11:28 PM 7/27/2005, you wrote:
>Gilles,
>
>Thanks for your reply. I have done some more work on the problem with a
>lot less fatigue clouding my judgement.
>
>I am using CW3.1 with Upgrade V1.3 for USB. I am not using the USB (the
>driver has broken and I haven't had time to figure out how to fix it). I
>am using the LPT version.
>
>My binary loads a Vector table into EEPROM at 0x400. The main program is
>located unbanked FLASH spaces at 0x4000 and 0xC000.
>
>To break the problem down, I have another EVB to which I have fitted a
>DG256 chip. This loads perfectly. Naturally this led me to believe that
>I have a hardware problem on my first board. I have checked each pin
>between the EVB connection and my board connection and can't find any
>difference - except that the EVB clock is 16MHz external and the board
>clock is 8MHz crystal.
>
>Long story short - It appeared that the EEPROM or FLASH was protected
>and was upsetting the burner on load. I started the debugger without
>loading the application. I then unsecured the chip - now it loads
>normally. The problem is how I got into this situation in the first
>place - this was a new chip and the board had no hardware faults - I
>suspect the chip was not erased out of the packet.
>
>My final question is - where does one find a list of MCUIDs. A search on
>the Freescale website yields nothing useful, there is nothing in the
>device documents save the PARTID and MEMSIZ registers which don't yield
>values like the MCUIDs. What am I missing?
>
>Thanks,
>
>Jonathan. >-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 27 July 2005 11:27 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] MCUID Frustration... >Hi Jonathan.
>
>Due to onchip resources overlap, the flash programming driver might
>relocate the eeprom to a different place to be able to program the
>eeprom.
>Before trying to isolate the problem, please tell me which version of
>CodeWarrior you use. Indeed, as everything, drivers are from time to
>time
>upgraded, and I need to check this issue on the same debugger.
>
>Regards,
>Gilles >At 02:43 PM 7/26/2005, you wrote:
> >Evening all.
> >
> >I have just spent the past hour trying to get a prototype with a
> >9S12DG256C soldered on working. The software was written and tested
>with
> >a DP256 EVB (with the "C" 2KX79 mask set chip inserted). With the new
> >board I have a specific problem:
> >
> >i) With the Metrowerks/ICD12 debugger that is coming up
> >with strange messages about there being no memory between 0x400 and
> >0x600 (EEPROM on a DP256).
> >ii) If I read the INITRM register on the DP256
> >immediately after reset, I get 0x01 - placing the EEPROM from 0x0000 to
> >0x0fff and enabled.
> >iii) If I read the INITRM register on the DG256C I get
>0x40
> >- placing the EEPROM from 0x4000 to 0x4fff and disabled.
> >
> >Search the Freescale web site for 9S12DG256C and get no results. Take
> >the "C" suffix off and get results for the 9S12DG256B. (This yields no
> >errata (hi Oliver ;)) for the 2KX79 mask set)
> >
> >Clearly I haven't understood some difference between the DP and DG
> >parts. Yet extensive searching of the "modular" data sheets has found
>no
> >occurrences of "MCUID" which I might use to check that the debugger is
> >using the correct FPP files. Nor since the DG data is the DP data can I
> >find any reason why EEPROM is being mapped at 0x4000 instead of 0x0400.
> >
> >I could assume that Freescale's documentation (while lacking and
>leaving
> >me without confidence (hi Oliver;)) is not incorrect. This takes me
>back
> >to the possibility I am having trouble driving the Metrowerks debugger
> >(but I won't even begin to offer my opinion of the Metrowerks help
> >system).
> >
> >Having had a whinge and got my frustrations out, can anyone suggest how
> >I might correctly tell the debugger that the EEPROM at 0x400 in the ELF
> >file really should be programmed at 0x400?
> >
> >Jonathan.
> >
> >
> >[Non-text portions of this message have been removed]
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>[Non-text portions of this message have been removed] >
>
>Yahoo! Groups Links
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
The MCUIDs list "belongs" for the HC(S)12 Family to the CodeWarrior HI-WAVE
debugger.
This list makes the link between part names and internal files/drivers to
use for a part. The list is stored in the "hc12.ini" file in "prog" folder.
The MCUID is a Legacy list defined years ago by Motorola for MMDS/MMEVS
emulators (HC05 and HC08 families), which actually return an MCUID
corresponding to the plugged Emulation Module.
This list got derived to HC(S)12 family for Motorola SDI cables support,
cables running with the same server/driver as the one used for MMDS/MMEVS.
If some MCUID information still appears in the debugger, this will in
feature be removed (let say, be transparent to the user), as Legacy cables
like SDI cannot stand latest silicons anyway.
Regards,
Gilles
At 11:28 PM 7/27/2005, you wrote:
>Gilles,
>
>Thanks for your reply. I have done some more work on the problem with a
>lot less fatigue clouding my judgement.
>
>I am using CW3.1 with Upgrade V1.3 for USB. I am not using the USB (the
>driver has broken and I haven't had time to figure out how to fix it). I
>am using the LPT version.
>
>My binary loads a Vector table into EEPROM at 0x400. The main program is
>located unbanked FLASH spaces at 0x4000 and 0xC000.
>
>To break the problem down, I have another EVB to which I have fitted a
>DG256 chip. This loads perfectly. Naturally this led me to believe that
>I have a hardware problem on my first board. I have checked each pin
>between the EVB connection and my board connection and can't find any
>difference - except that the EVB clock is 16MHz external and the board
>clock is 8MHz crystal.
>
>Long story short - It appeared that the EEPROM or FLASH was protected
>and was upsetting the burner on load. I started the debugger without
>loading the application. I then unsecured the chip - now it loads
>normally. The problem is how I got into this situation in the first
>place - this was a new chip and the board had no hardware faults - I
>suspect the chip was not erased out of the packet.
>
>My final question is - where does one find a list of MCUIDs. A search on
>the Freescale website yields nothing useful, there is nothing in the
>device documents save the PARTID and MEMSIZ registers which don't yield
>values like the MCUIDs. What am I missing?
>
>Thanks,
>
>Jonathan. >-----Original Message-----
>From: 68HC12@68HC... [mailto:68HC12@68HC...] On Behalf
>Of Gilles Blanquin
>Sent: Wednesday, 27 July 2005 11:27 PM
>To: 68HC12@68HC...
>Subject: RE: [68HC12] MCUID Frustration... >Hi Jonathan.
>
>Due to onchip resources overlap, the flash programming driver might
>relocate the eeprom to a different place to be able to program the
>eeprom.
>Before trying to isolate the problem, please tell me which version of
>CodeWarrior you use. Indeed, as everything, drivers are from time to
>time
>upgraded, and I need to check this issue on the same debugger.
>
>Regards,
>Gilles >At 02:43 PM 7/26/2005, you wrote:
> >Evening all.
> >
> >I have just spent the past hour trying to get a prototype with a
> >9S12DG256C soldered on working. The software was written and tested
>with
> >a DP256 EVB (with the "C" 2KX79 mask set chip inserted). With the new
> >board I have a specific problem:
> >
> >i) With the Metrowerks/ICD12 debugger that is coming up
> >with strange messages about there being no memory between 0x400 and
> >0x600 (EEPROM on a DP256).
> >ii) If I read the INITRM register on the DP256
> >immediately after reset, I get 0x01 - placing the EEPROM from 0x0000 to
> >0x0fff and enabled.
> >iii) If I read the INITRM register on the DG256C I get
>0x40
> >- placing the EEPROM from 0x4000 to 0x4fff and disabled.
> >
> >Search the Freescale web site for 9S12DG256C and get no results. Take
> >the "C" suffix off and get results for the 9S12DG256B. (This yields no
> >errata (hi Oliver ;)) for the 2KX79 mask set)
> >
> >Clearly I haven't understood some difference between the DP and DG
> >parts. Yet extensive searching of the "modular" data sheets has found
>no
> >occurrences of "MCUID" which I might use to check that the debugger is
> >using the correct FPP files. Nor since the DG data is the DP data can I
> >find any reason why EEPROM is being mapped at 0x4000 instead of 0x0400.
> >
> >I could assume that Freescale's documentation (while lacking and
>leaving
> >me without confidence (hi Oliver;)) is not incorrect. This takes me
>back
> >to the possibility I am having trouble driving the Metrowerks debugger
> >(but I won't even begin to offer my opinion of the Metrowerks help
> >system).
> >
> >Having had a whinge and got my frustrations out, can anyone suggest how
> >I might correctly tell the debugger that the EEPROM at 0x400 in the ELF
> >file really should be programmed at 0x400?
> >
> >Jonathan.
> >
> >
> >[Non-text portions of this message have been removed]
> >
> >
> >
> >
> >> Terms of Service.
>
> _____ >
>[Non-text portions of this message have been removed] >
>
>Yahoo! Groups Links
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks Ver3.1 & DBug12 Flash Programming - hebs_s - Jul 28 9:47:00 2005
Gilles,
Thanks.
I was struggling to program flash using Metrowerks with DBug12.
Is there any other mode other than POD mode does it support flash
programming using Metrowerks?
regards,
hebs --- In 68HC12@68HC..., Gilles Blanquin <gilles.blanquin@f...>
wrote:
>
> Hi.
>
> The D-bug12 is a Legacy host target interface provided "as is" for
backward
> compatibility purposes in Metrowerks Ver 3.0 & Ver 3.1.
>
> Also the flash programming support as never been implemented in the
D-bug12
> Target Interface, when the target board is used in POD mode.
>
> Regards,
> Gilles > At 01:56 PM 7/26/2005, you wrote:
> >Hi,
> >
> >All!
> >
> >I am using Debug12 for Flash programming of target borad in POD
> >using Evaluation board.It is possible to program &erase target
flash
> >using HyperTerminal as Terminal Emulation program.
> >
> >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the
Flash
> >but unable to do so.It is giving an error.
> >
> >Is this the limitation of Metrowerks? Request to answer if you know
> >exactly the possible causes.
> >
> >Pl confirm.Thanks in anticipation.
> >
> >regards,
> >hebs
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
>
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Thanks.
I was struggling to program flash using Metrowerks with DBug12.
Is there any other mode other than POD mode does it support flash
programming using Metrowerks?
regards,
hebs --- In 68HC12@68HC..., Gilles Blanquin <gilles.blanquin@f...>
wrote:
>
> Hi.
>
> The D-bug12 is a Legacy host target interface provided "as is" for
backward
> compatibility purposes in Metrowerks Ver 3.0 & Ver 3.1.
>
> Also the flash programming support as never been implemented in the
D-bug12
> Target Interface, when the target board is used in POD mode.
>
> Regards,
> Gilles > At 01:56 PM 7/26/2005, you wrote:
> >Hi,
> >
> >All!
> >
> >I am using Debug12 for Flash programming of target borad in POD
> >using Evaluation board.It is possible to program &erase target
flash
> >using HyperTerminal as Terminal Emulation program.
> >
> >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the
Flash
> >but unable to do so.It is giving an error.
> >
> >Is this the limitation of Metrowerks? Request to answer if you know
> >exactly the possible causes.
> >
> >Pl confirm.Thanks in anticipation.
> >
> >regards,
> >hebs
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
>
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Re: Metrowerks Ver3.1 & DBug12 Flash Programming - Gilles Blanquin - Jul 28 11:00:00 2005
Hi Hebs.
There is no way to flash through the D-bug12 connection.
If you want to flash, you will have to connect via the BDM port with a
third party cable, like a P&E Multilink or SofTec inDART-HCS12 (these are
supported by CodeWarrior).
Regards,
Gilles At 03:47 PM 7/28/2005, you wrote:
>Gilles,
>
>Thanks.
>
>I was struggling to program flash using Metrowerks with DBug12.
>
>Is there any other mode other than POD mode does it support flash
>programming using Metrowerks?
>
>regards,
>hebs >--- In 68HC12@68HC..., Gilles Blanquin <gilles.blanquin@f...>
>wrote:
> >
> > Hi.
> >
> > The D-bug12 is a Legacy host target interface provided "as is" for
>backward
> > compatibility purposes in Metrowerks Ver 3.0 & Ver 3.1.
> >
> > Also the flash programming support as never been implemented in the
>D-bug12
> > Target Interface, when the target board is used in POD mode.
> >
> > Regards,
> > Gilles
> >
> >
> > At 01:56 PM 7/26/2005, you wrote:
> > >Hi,
> > >
> > >All!
> > >
> > >I am using Debug12 for Flash programming of target borad in POD
> > >using Evaluation board.It is possible to program &erase target
>flash
> > >using HyperTerminal as Terminal Emulation program.
> > >
> > >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the
>Flash
> > >but unable to do so.It is giving an error.
> > >
> > >Is this the limitation of Metrowerks? Request to answer if you know
> > >exactly the possible causes.
> > >
> > >Pl confirm.Thanks in anticipation.
> > >
> > >regards,
> > >hebs
> > >
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >Yahoo! Groups Links
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
There is no way to flash through the D-bug12 connection.
If you want to flash, you will have to connect via the BDM port with a
third party cable, like a P&E Multilink or SofTec inDART-HCS12 (these are
supported by CodeWarrior).
Regards,
Gilles At 03:47 PM 7/28/2005, you wrote:
>Gilles,
>
>Thanks.
>
>I was struggling to program flash using Metrowerks with DBug12.
>
>Is there any other mode other than POD mode does it support flash
>programming using Metrowerks?
>
>regards,
>hebs >--- In 68HC12@68HC..., Gilles Blanquin <gilles.blanquin@f...>
>wrote:
> >
> > Hi.
> >
> > The D-bug12 is a Legacy host target interface provided "as is" for
>backward
> > compatibility purposes in Metrowerks Ver 3.0 & Ver 3.1.
> >
> > Also the flash programming support as never been implemented in the
>D-bug12
> > Target Interface, when the target board is used in POD mode.
> >
> > Regards,
> > Gilles
> >
> >
> > At 01:56 PM 7/26/2005, you wrote:
> > >Hi,
> > >
> > >All!
> > >
> > >I am using Debug12 for Flash programming of target borad in POD
> > >using Evaluation board.It is possible to program &erase target
>flash
> > >using HyperTerminal as Terminal Emulation program.
> > >
> > >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the
>Flash
> > >but unable to do so.It is giving an error.
> > >
> > >Is this the limitation of Metrowerks? Request to answer if you know
> > >exactly the possible causes.
> > >
> > >Pl confirm.Thanks in anticipation.
> > >
> > >regards,
> > >hebs
> > >
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> > >Yahoo! Groups Links
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks Ver3.1 & DBug12 Flash Programming - Jefferson Smith - Jul 28 12:00:00 2005
You would be able to flash with D-Bug12 if you had a compatible loader
utility. First, it nees srecord (s19) format. I've used HyperTerminal
but with bad results (I had to add 1 ms delay between chars) because
flow control was not working right. My coleague used RealTerm, which
seems to work. All you are doing in D-Bug12 is typing the right
command, then streaming the S19 file to the board. --jeffs --- In 68HC12@68HC..., Gilles Blanquin <gilles.blanquin@f...>
wrote:
> Hi Hebs.
>
> There is no way to flash through the D-bug12 connection.
> If you want to flash, you will have to connect via the BDM port with a
> third party cable, like a P&E Multilink or SofTec inDART-HCS12
(these are
> supported by CodeWarrior).
>
> Regards,
> Gilles > At 03:47 PM 7/28/2005, you wrote:
> >Gilles,
> >
> >Thanks.
> >
> >I was struggling to program flash using Metrowerks with DBug12.
> >
> >Is there any other mode other than POD mode does it support flash
> >programming using Metrowerks?
> >
> >regards,
> >hebs
> >
> >
> >--- In 68HC12@68HC..., Gilles Blanquin <gilles.blanquin@f...>
> >wrote:
> > >
> > > Hi.
> > >
> > > The D-bug12 is a Legacy host target interface provided "as is" for
> >backward
> > > compatibility purposes in Metrowerks Ver 3.0 & Ver 3.1.
> > >
> > > Also the flash programming support as never been implemented in the
> >D-bug12
> > > Target Interface, when the target board is used in POD mode.
> > >
> > > Regards,
> > > Gilles
> > >
> > >
> > > At 01:56 PM 7/26/2005, you wrote:
> > > >Hi,
> > > >
> > > >All!
> > > >
> > > >I am using Debug12 for Flash programming of target borad in POD
> > > >using Evaluation board.It is possible to program &erase target
> >flash
> > > >using HyperTerminal as Terminal Emulation program.
> > > >
> > > >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the
> >Flash
> > > >but unable to do so.It is giving an error.
> > > >
> > > >Is this the limitation of Metrowerks? Request to answer if you know
> > > >exactly the possible causes.
> > > >
> > > >Pl confirm.Thanks in anticipation.
> > > >
> > > >regards,
> > > >hebs
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
>
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
utility. First, it nees srecord (s19) format. I've used HyperTerminal
but with bad results (I had to add 1 ms delay between chars) because
flow control was not working right. My coleague used RealTerm, which
seems to work. All you are doing in D-Bug12 is typing the right
command, then streaming the S19 file to the board. --jeffs --- In 68HC12@68HC..., Gilles Blanquin <gilles.blanquin@f...>
wrote:
> Hi Hebs.
>
> There is no way to flash through the D-bug12 connection.
> If you want to flash, you will have to connect via the BDM port with a
> third party cable, like a P&E Multilink or SofTec inDART-HCS12
(these are
> supported by CodeWarrior).
>
> Regards,
> Gilles > At 03:47 PM 7/28/2005, you wrote:
> >Gilles,
> >
> >Thanks.
> >
> >I was struggling to program flash using Metrowerks with DBug12.
> >
> >Is there any other mode other than POD mode does it support flash
> >programming using Metrowerks?
> >
> >regards,
> >hebs
> >
> >
> >--- In 68HC12@68HC..., Gilles Blanquin <gilles.blanquin@f...>
> >wrote:
> > >
> > > Hi.
> > >
> > > The D-bug12 is a Legacy host target interface provided "as is" for
> >backward
> > > compatibility purposes in Metrowerks Ver 3.0 & Ver 3.1.
> > >
> > > Also the flash programming support as never been implemented in the
> >D-bug12
> > > Target Interface, when the target board is used in POD mode.
> > >
> > > Regards,
> > > Gilles
> > >
> > >
> > > At 01:56 PM 7/26/2005, you wrote:
> > > >Hi,
> > > >
> > > >All!
> > > >
> > > >I am using Debug12 for Flash programming of target borad in POD
> > > >using Evaluation board.It is possible to program &erase target
> >flash
> > > >using HyperTerminal as Terminal Emulation program.
> > > >
> > > >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the
> >Flash
> > > >but unable to do so.It is giving an error.
> > > >
> > > >Is this the limitation of Metrowerks? Request to answer if you know
> > > >exactly the possible causes.
> > > >
> > > >Pl confirm.Thanks in anticipation.
> > > >
> > > >regards,
> > > >hebs
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
>
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks Ver3.1 & DBug12 Flash Programming - Joe McCarron - Jul 28 12:03:00 2005
How about the uBug12 app ?
Thats what i use to dl to
flash via a serial cable
--Joe --- In 68HC12@68HC..., Gilles Blanquin
<gilles.blanquin@f...> wrote:
> Hi Hebs.
>
> There is no way to flash through the D-bug12 connection.
> If you want to flash, you will have to connect via the BDM port
with a
> third party cable, like a P&E Multilink or SofTec inDART-HCS12
(these are
> supported by CodeWarrior).
>
> Regards,
> Gilles > At 03:47 PM 7/28/2005, you wrote:
> >Gilles,
> >
> >Thanks.
> >
> >I was struggling to program flash using Metrowerks with DBug12.
> >
> >Is there any other mode other than POD mode does it support flash
> >programming using Metrowerks?
> >
> >regards,
> >hebs
> >
> >
> >--- In 68HC12@68HC..., Gilles Blanquin
<gilles.blanquin@f...>
> >wrote:
> > >
> > > Hi.
> > >
> > > The D-bug12 is a Legacy host target interface provided "as is"
for
> >backward
> > > compatibility purposes in Metrowerks Ver 3.0 & Ver 3.1.
> > >
> > > Also the flash programming support as never been implemented
in the
> >D-bug12
> > > Target Interface, when the target board is used in POD mode.
> > >
> > > Regards,
> > > Gilles
> > >
> > >
> > > At 01:56 PM 7/26/2005, you wrote:
> > > >Hi,
> > > >
> > > >All!
> > > >
> > > >I am using Debug12 for Flash programming of target borad in
POD
> > > >using Evaluation board.It is possible to program &erase target
> >flash
> > > >using HyperTerminal as Terminal Emulation program.
> > > >
> > > >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the
> >Flash
> > > >but unable to do so.It is giving an error.
> > > >
> > > >Is this the limitation of Metrowerks? Request to answer if
you know
> > > >exactly the possible causes.
> > > >
> > > >Pl confirm.Thanks in anticipation.
> > > >
> > > >regards,
> > > >hebs
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
>
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Thats what i use to dl to
flash via a serial cable
--Joe --- In 68HC12@68HC..., Gilles Blanquin
<gilles.blanquin@f...> wrote:
> Hi Hebs.
>
> There is no way to flash through the D-bug12 connection.
> If you want to flash, you will have to connect via the BDM port
with a
> third party cable, like a P&E Multilink or SofTec inDART-HCS12
(these are
> supported by CodeWarrior).
>
> Regards,
> Gilles > At 03:47 PM 7/28/2005, you wrote:
> >Gilles,
> >
> >Thanks.
> >
> >I was struggling to program flash using Metrowerks with DBug12.
> >
> >Is there any other mode other than POD mode does it support flash
> >programming using Metrowerks?
> >
> >regards,
> >hebs
> >
> >
> >--- In 68HC12@68HC..., Gilles Blanquin
<gilles.blanquin@f...>
> >wrote:
> > >
> > > Hi.
> > >
> > > The D-bug12 is a Legacy host target interface provided "as is"
for
> >backward
> > > compatibility purposes in Metrowerks Ver 3.0 & Ver 3.1.
> > >
> > > Also the flash programming support as never been implemented
in the
> >D-bug12
> > > Target Interface, when the target board is used in POD mode.
> > >
> > > Regards,
> > > Gilles
> > >
> > >
> > > At 01:56 PM 7/26/2005, you wrote:
> > > >Hi,
> > > >
> > > >All!
> > > >
> > > >I am using Debug12 for Flash programming of target borad in
POD
> > > >using Evaluation board.It is possible to program &erase target
> >flash
> > > >using HyperTerminal as Terminal Emulation program.
> > > >
> > > >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program the
> >Flash
> > > >but unable to do so.It is giving an error.
> > > >
> > > >Is this the limitation of Metrowerks? Request to answer if
you know
> > > >exactly the possible causes.
> > > >
> > > >Pl confirm.Thanks in anticipation.
> > > >
> > > >regards,
> > > >hebs
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >Yahoo! Groups Links
> > > >
> > > >
> > > >
> > > >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
>
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
Re: Metrowerks Ver3.1 & DBug12 Flash Programming - microcodefun - Jul 29 4:45:00 2005
Here are some comments based on my experience with DBug12.
1) As far as I know uBug12 can only communicate with the Freescale
Serial Monitor as described in their appnote 2548, not with the DBug12
monitor.
2) You should be able to use Hyperterminal for this. I personally
prefer using MiniIDE (www.mgtek.com/miniide). Either way, make sure
you enabled support for Xon/Xoff for the COM port in your terminal
program.
3) If you still get errors, inspect your S-record file. Sometimes
Metrowerks generates a really long S0 line in there. This is usually
the first line in the S-record. If so, try replacing it with something
shorter, for example: S0030000FC. You can find more about this in
appnote AN1002 on my website (www.feaser.com).
4) You can use NoICE debugger for programming S-records using a DBug12
POD connected to your target board. Simply select microBDM12SX as the
communication interface. This worked for me with V4.0.0b26 of DBug12.
Good luck with it!
-Frank
--------------------------
More HC12 resources at:
http://www.feaser.com
http://www.driver2go.net
--------------------------
--- In 68HC12@68HC..., "Joe McCarron" <joemccarr@y...> wrote:
> How about the uBug12 app ?
>
> Thats what i use to dl to
> flash via a serial cable
>
> --Joe > > > > >Hi,
> > > > >
> > > > >All!
> > > > >
> > > > >I am using Debug12 for Flash programming of target borad in
> POD
> > > > >using Evaluation board.It is possible to program &erase
target
> > >flash
> > > > >using HyperTerminal as Terminal Emulation program.
> > > > >
> > > > >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program
the
> > >Flash
> > > > >but unable to do so.It is giving an error.
> > > > >
> > > > >Is this the limitation of Metrowerks? Request to answer if
> you know
> > > > >exactly the possible causes.
> > > > >
> > > > >Pl confirm.Thanks in anticipation.
> > > > >
> > > > >regards,
> > > > >hebs
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> >
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )
1) As far as I know uBug12 can only communicate with the Freescale
Serial Monitor as described in their appnote 2548, not with the DBug12
monitor.
2) You should be able to use Hyperterminal for this. I personally
prefer using MiniIDE (www.mgtek.com/miniide). Either way, make sure
you enabled support for Xon/Xoff for the COM port in your terminal
program.
3) If you still get errors, inspect your S-record file. Sometimes
Metrowerks generates a really long S0 line in there. This is usually
the first line in the S-record. If so, try replacing it with something
shorter, for example: S0030000FC. You can find more about this in
appnote AN1002 on my website (www.feaser.com).
4) You can use NoICE debugger for programming S-records using a DBug12
POD connected to your target board. Simply select microBDM12SX as the
communication interface. This worked for me with V4.0.0b26 of DBug12.
Good luck with it!
-Frank
--------------------------
More HC12 resources at:
http://www.feaser.com
http://www.driver2go.net
--------------------------
--- In 68HC12@68HC..., "Joe McCarron" <joemccarr@y...> wrote:
> How about the uBug12 app ?
>
> Thats what i use to dl to
> flash via a serial cable
>
> --Joe > > > > >Hi,
> > > > >
> > > > >All!
> > > > >
> > > > >I am using Debug12 for Flash programming of target borad in
> POD
> > > > >using Evaluation board.It is possible to program &erase
target
> > >flash
> > > > >using HyperTerminal as Terminal Emulation program.
> > > > >
> > > > >Howver with Metrowerks Ver 3.0 & Ver 3.1 tested to program
the
> > >Flash
> > > > >but unable to do so.It is giving an error.
> > > > >
> > > > >Is this the limitation of Metrowerks? Request to answer if
> you know
> > > > >exactly the possible causes.
> > > > >
> > > > >Pl confirm.Thanks in anticipation.
> > > > >
> > > > >regards,
> > > > >hebs
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >Yahoo! Groups Links
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
> > >
> > >
> > >Yahoo! Groups Links
> > >
> > >
> > >
> >
______________________________
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )