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

Hello everyone my name is Cristian and I am new to the group, I been reading some of the post place on the eeprom section but I have not found what I am looking for.
My question is, does anyone know to burn my program (C code written on icc12) to my Motorola 68hc12b board. I have tried to look online and I have also call the tech support but the code I have found is written on ASM and icc12 does not support ASM code. Someone in my school told me that I need to include the “VECTORS.H” file to be able to compile but I have not found it yet. Any ideas please??



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

c...@yahoo.com wrote:

> Hello everyone my name is Cristian and I am new to the group, I been
> reading some of the post place on the eeprom section but I have not found
> what I am looking for.
> My question is, does anyone know to burn my program (C code written on
> icc12) to my Motorola 68hc12b board. I have tried to look online and I
> have also call the tech support but the code I have found is written on
> ASM and icc12 does not support ASM code. Someone in my school told me that
> I need to include the "VECTORS.H" file to be able to compile but I have
> not found it yet. Any ideas please??
It's not true that ICC12 doesn't support assembler code. In fact it does.
Imagecraft FAQ:

http://www.dragonsgate.net/FAQ/cache/2.html
"vectors.h" isn't necessary for every ICC12 project. First of all it's not
vectors.h but vectors.c and that file can be found in icc12\examples folder.
It's just an example of how you can specify HC12 reset and interrupt vectors
in ICC12. You can use assembler to specify reset vectors. You also may
prefer to follow the vectors.c example but specify interrupt vectors not in
common vectors.c file but in relevent source files, for example SCI
interrupt vector in sci.c file, SPI vector in spi.c etc. Something more
modular but it's a matter of taste.

Edward



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hello Christian !

Below what I use to develop for 9s12=A0:
- icc12 compiler
- NoIce debugger, which can burn program into 9s12
- BDM multilink either on parallel port, either on USB port

I don't understand exactly what you want : 9s12 presents 3 types of memory =
:
- RAM
- EEProm
- Flash
Usually your program resides in flash memory... EEProm allows you to store =
constants...
So, do you want to download program in Flash or in EEProm ?

Anyway, you have to write somewhere code for interrupt vectors. Below is my=
Vectors.c file (it is a ".C" file, not ".H" here). ".H"
files are used for prototyping functions, typedef... not for code.

As you can see, for 9s12dp256, I define all interrupt vectors, sometime wit=
h infinite loop function, sometime with external function
I develop in an other file. Under BDM, if my program locks, I can stop it a=
nd see in which interrupt function it is. In real system,
if program fall into a undefined interrupt function, watchdog will restart =
processor.

With ICC12 and NoIce, you can compile for RAM area or flash area. I use the=
first possibility to check some little functions (9s12
owns 12 Kb Ram), and the second of course for the all project.

In ICC12, project, you can have for example
- your main file
- vector.c file
Under Compiler/Options, you select your device for flash memory, or "custom=
" with Program Memory 0xD000, Stack Pointer 0xff80 for
compile to Ram memory

In NoIce, you can download your file in RAM or Flash area.
For download in RAM area, I use a file with some instructions for preparing=
the processor.

Ask if you need other details.

I hope this will help you.

Joel
//*************************************************************************=
********************
// My vector.c file
#include

#pragma nonpaged_function _start
extern void _start(void); // entry point in crt??.s
#pragma interrupt_handler ISR_NonDeveloppe
void ISR_NonDeveloppe (void) { while (1) ; }

#pragma interrupt_handler ISR_Sci1
void ISR_Sci1 (void) { while (1) ; }
//extern void ISR_Sci1 (void);

#pragma interrupt_handler ISR_Sci0
//void ISR_Sci0 (void) { while (1) ; }
extern void ISR_Sci0 (void);
#pragma interrupt_handler ISR_Rti
//void ISR_Rti(void) { while (1) ; }
extern void ISR_Rti (void);

#pragma interrupt_handler ISR_TimerModulus
void ISR_TimerModulus (void) { while (1) ; }
//extern void ISR_TimerModulus (void);
#pragma interrupt_handler ISR_Timer0
void ISR_Timer0(void) { while (1) ; }

#pragma interrupt_handler ISR_Timer1
void ISR_Timer1(void) { while (1) ; }

#pragma interrupt_handler ISR_Timer2
void ISR_Timer2(void) { while (1) ; }

#pragma interrupt_handler ISR_Timer3
void ISR_Timer3(void) { while (1) ; }

#pragma interrupt_handler ISR_Timer4
void ISR_Timer4(void) { while (1) ; }

#pragma interrupt_handler ISR_Timer5
void ISR_Timer5(void) { while (1) ; }

#pragma interrupt_handler ISR_Timer6
void ISR_Timer6(void) { while (1) ; }
//extern void ISR_Timer6 (void);

#pragma interrupt_handler ISR_Timer7
//void ISR_Timer7(void) { while (1) ; }
extern void ISR_Timer7 (void);
//*********************************************************
// change the address if your vector starts elsewhere
// Processeur 9S12DP256 : vecteurs interruptions en 0xff80
#pragma abs_address:0xFF80

void (*interrupt_vectors[])(void) =3D
{
// to cast a constant, say 0xb600, use (void (*)())0xb600
// Tous les vecteurs interrupt occupent 2 octets cons=E9cutifs. Ainsi
// l'adresse de la routine d'interruption RTI est d=E9finie aux
// adresses $FFF0-$FFF1
ISR_NonDeveloppe, // Reserved $FF80
ISR_NonDeveloppe, // Reserved $FF82
ISR_NonDeveloppe, // Reserved $FF84
ISR_NonDeveloppe, // Reserved $FF86
ISR_NonDeveloppe, // Reserved $FF88
ISR_NonDeveloppe, // Reserved $FF8A
ISR_NonDeveloppe, // $FF8C PWM Emergency Shutdown
ISR_NonDeveloppe, // $FF8E Port P Interrupt
ISR_NonDeveloppe, // $FF90 MSCAN 4 Transmit
ISR_NonDeveloppe, // $FF92 MSCAN 4 Receive
ISR_NonDeveloppe, // $FF94 MSCAN 4 Error
ISR_NonDeveloppe, // $FF96 MSCAN 4 Wake-up
ISR_NonDeveloppe, // $FF98 MSCAN 3 Transmit
ISR_NonDeveloppe, // $FF9A MSCAN 3 Receive
ISR_NonDeveloppe, // $FF9C MSCAN 3 Error
ISR_NonDeveloppe, // $FF9E MSCAN 3 Wake-up
ISR_NonDeveloppe, // $FFA0 MSCAN 2 Transmit
ISR_NonDeveloppe, // $FFA2 MSCAN 2 Receive
ISR_NonDeveloppe, // $FFA4 MSCAN 2 Error
ISR_NonDeveloppe, // $FFA6 MSCAN 2 Wake-up
ISR_NonDeveloppe, // $FFA8 MSCAN 1 Transmit
ISR_NonDeveloppe, // $FFAA MSCAN 1 Receive
ISR_NonDeveloppe, // $FFAC MSCAN 1 Error
ISR_NonDeveloppe, // $FFAE MSCAN 1 Wake-up
ISR_NonDeveloppe, // $FFB0 MSCAN 0 Transmit
ISR_NonDeveloppe, // $FFB2 MSCAN 0 Receive
ISR_NonDeveloppe, // $FFB4 MSCAN 0 Error
ISR_NonDeveloppe, // $FFB6 MSCAN 0 Wake-up
ISR_NonDeveloppe, // $FFB8 Flash
ISR_NonDeveloppe, // $FFBA EEPROM
ISR_NonDeveloppe, // $FFBC SPI2
ISR_NonDeveloppe, // $FFBE SPI1
ISR_NonDeveloppe, // $FFC0 IIC Bus
ISR_NonDeveloppe, // $FFC2 BDLC
ISR_NonDeveloppe, // $FFC4 CRG Self Clock Mode
ISR_NonDeveloppe, // $FFC6 CRG PLL Lock

ISR_NonDeveloppe, // $FFC8 Pulse Accumulator B Overflow
ISR_TimerModulus, // $FFCA Modulus Down Counter Underflow

ISR_NonDeveloppe, // $FFCC Port H Interrupt
ISR_NonDeveloppe, // $FFCE Port J Interrupt
ISR_NonDeveloppe, // $FFD0 ATD1
ISR_NonDeveloppe, // $FFD2 ATD0
ISR_Sci1, // $FFD4 SCI1
ISR_Sci0, // $FFD6 SCI0

ISR_NonDeveloppe, // $FFD8 SPI0
ISR_NonDeveloppe, // $FFDA Pulse Accumulator A Input Edge
ISR_NonDeveloppe, // $FFDC Pulse Accumulator A Overflow

ISR_NonDeveloppe, // $FFDE Timer Overflow
ISR_Timer7, // $FFE0 Timer Channel 7
ISR_Timer6, // $FFE2 Timer Channel 6
ISR_Timer5, // $FFE4 Timer Channel 5
ISR_Timer4, // $FFE6 Timer Channel 4
ISR_Timer3, // $FFE8 Timer Channel 3
ISR_Timer2, // $FFEA Timer Channel 2
ISR_Timer1, // $FFEC Timer Channel 1
ISR_Timer0, // $FFEE Timer Channel 0
ISR_Rti, // $FFF0 Real Time Interrupt
ISR_NonDeveloppe, // $FFF2 IRQ
ISR_NonDeveloppe, // $FFF4 XIRQ
ISR_NonDeveloppe, // $FFF6 SWI
ISR_NonDeveloppe, // $FFF8 Unimplement Intruction Trap
ISR_NonDeveloppe, // $FFFA COP failure reset
ISR_NonDeveloppe, // $FFFC Clock monitor fail reset
_start, // $FFFE Reset
};

//*************************************************************************=
********************

-----Message d'origine-----
De=A0: 6...@yahoogroups.com [mailto:6...@yahoogroups.com] De la part de=
c...@yahoo.com
Envoy=E9=A0: mardi 10 octobre 2006 17:48
=C0=A0: 6...@yahoogroups.com
Objet=A0: [68HC12] Burning into the eeprom

Hello everyone my name is Cristian and I am new to the group, I been readin=
g some of the post place on the eeprom section but I have
not found what I am looking for.=20
My question is, does anyone know to burn my program (C code written on icc1=
2) to my Motorola 68hc12b board. I have tried to look
online and I have also call the tech support but the code I have found is w=
ritten on ASM and icc12 does not support ASM code.
Someone in my school told me that I need to include the =93VECTORS.H=94 fil=
e to be able to compile but I have not found it yet. Any
ideas please??

=20

=20


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, caroboy@... wrote:
> My question is, does anyone know to burn my program (C code
> written on icc12) to my Motorola 68hc12b board.

Hi,
I'm certain there are not many of us developers who do not know how to
burn to the device. Afterall, I would have had to find another job
years ago if not :)

Perhaps you have D-Bug12. I use that in monitor, bootloader, and BDM
POD modes. Please tell us what kind of BDM or Monitor interface you
have, and we can help more.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, caroboy@... wrote:
>> My question is, does anyone know to burn my program (C code
>> written on icc12) to my Motorola 68hc12b board.
>
>Hi,
>I'm certain there are not many of us developers who do not know how to
>burn to the device. Afterall, I would have had to find another job
>years ago if not :)
>
>Perhaps you have D-Bug12. I use that in monitor, bootloader, and BDM
>POD modes. Please tell us what kind of BDM or Monitor interface you
>have, and we can help more.

Thank you very much everyone for responding for my posting, as you can all notice I am a beginner with this board (Motorola cme 68hc12b) and also with icc12 interface, I have also used MiniIDE but the program I created is done on C (I know Assembly but I am not an expert, that is why I choose C). Well since we are the second team to be using this board with icc12 no one at school could help us.
Thus our project is trial an error, I would like to ask all of you experts out there if there is a possibility to clear (flush) the serial port, output send by the board.
Hope this explain my problem in detail:
My program is simple is just an infinite loop that display “open” or “close” when a sensor is either open or closed. In the second part of the program I am using java (because we need to create an interface for the project)to read the serial input (it does read) but the problem is that there is some garbage at the beginning of the reading
Ex.
%open (it varies from output)
Can someone advice on some ideas on how to fix this, or is there a command used by the icc12 to flush the port after and before it sends the output?

Thank you all



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hello, Christian !

Continue to program in C language !!!

It's easy to pass parameters between C functions : compiler put the correct code to pass them and retrieve values. Try to do that in
assembly !

It's easy to build data structures in C : compiler put the correct code to access the different members of the structure. Try to do
that in assembly !

C language is independent enough of the processor. I reused some code written in C for 8751 processor in new development using 9s12.
If your C code doesn't use the internal architecture of the processor, this code can be used with any processor.

And C language allow to access any internal register of the processor... So, often, C is as a "high level assembly". "In fine",
ICC12, and all compilers I know, allows you to put assembly code into C functions, so the compiler write the correct statements for
parameters, and you can write what you want in assembly code into the function.

For me, I write about 99% of my development in C, and 1% in assembly language, when I want to run quickly. And sometimes, assembly
language isn't faster than code generated with C compiler ! A complete project means about 200 Kbytes in the flash memory.

Joel



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

Hello everyone,

I did once develop a monitoring application on a Minidragon+ borad (using
9s12dp256).. i tested that my program was working fine in RAM mode .. how do
you normally store your completed code the EEPROM or FLASH memory?

I thought D-Bug12 occupies part of the FLASH memory and erasing and
re-programming the FLASH means that we will loose D-Bug12...

can anyone provide me with more information about storing code for
auto-start purposes? (ex: monitoring a physical variable over a period of
time by means of an RTI and starting the board using a switch)).

MK
[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 )

--- In 6...@yahoogroups.com, "Mohammed El Korek"
wrote:
>
> Hello everyone,
>
> I did once develop a monitoring application on a Minidragon+ borad
(using
> 9s12dp256).. i tested that my program was working fine in RAM mode
.. how do
> you normally store your completed code the EEPROM or FLASH memory?
>
> I thought D-Bug12 occupies part of the FLASH memory and erasing and
> re-programming the FLASH means that we will loose D-Bug12...

1. link the program to different addresses. 0x1000 was program and
data so now I move program to [0x4000..0x7fff] (fixed Flash bank).

2. The vector table is more tricky because of the multiple
possibilities. With full DBug12 in Flash, the RAM vector table is 0x3e00.
- I move it to [0xff80..0xffff] because I use a Debug12 BDM POD to
erase ALL of Flash, and that is where the CPU looks at powerup.
- Sometimes I use Debug12 bootloader. It enables using all flash
except [0xf000..0xffff] where the bootloader remains. In this case the
bootloader will use my vector table at [0xef80..0xefff]. In all vector
tables, the last two bytes are the start vector.

This answers all the questions, but some will have to ask how to do
something specific like put the addresses in the vector table. Make
sure you clarify what tools you're compiling with.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Mohammed El Korek"
wrote:

> how do you normally store your completed code the EEPROM or FLASH
> memory?
...
> I thought D-Bug12 occupies part of the FLASH memory and erasing and
> re-programming the FLASH means that we will loose D-Bug12...

This should be possible since there's 256K of flash and D-bug12 uses
less than half of that. Most people think that you can't keep d-bug12
because of the vector area, but I think you can put your own vectors
in eeprom, and use the "jump to EEPROM" DIP switch to run your program:

http://tech.groups.yahoo.com/group/68HC12/message/14322

But I haven't tried this yet. It's only an idea.

Eric



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Eric Engler" wrote:
> This should be possible since there's 256K of flash and D-bug12 uses
> less than half of that. Most people think that you can't keep d-bug12
> because of the vector area, but I think you can put your own vectors
> in eeprom, and use the "jump to EEPROM" DIP switch to run your program:
>
> http://tech.groups.yahoo.com/group/68HC12/message/14322
>
> But I haven't tried this yet. It's only an idea.
>
> Eric
>

Well the common problem with keeping DBug12 and your app in Flash is
the bootloader only knows how to delete both and not leave DBug12. You
would have to reload both DBug12 and your app everytime you make
changes to your app. If you have a BDM debugger, you don't need DBug12
on there at all.

It doesn't make sense what you said about puting vectors in EEPROM.
With DBug12 present, IRQs are forwarded to the 0x3c00 table in RAM.
The purpose for "jump to EE" is so you would not have to type a
command to start your program that is loaded in Flash. Still, you
would also not have all the interrupt vectors available because you
left DBug12 in there to steal at least the SCI0, swi, and start vectors.



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

--- In 6...@yahoogroups.com, "Jefferson Smith" wrote:

> Well the common problem with keeping DBug12 and your app in Flash is
> the bootloader only knows how to delete both and not leave DBug12.

My plan was to D/L the serial monitor into RAM and use that to program
flash. It's very small and easy to modify as needed. I'd use d-bug12
to D/L the serial monitor into RAM, and then it would run and most of
my PC-side code would interact with the serial monitor.

I'm not sure if the DP256 allows erasing only part of the flash (do
they let you erase only 1 bank at a time?), but if not, it's still not
hard to re-program d-bug12 using the serial monitor at 115K. It should
only take a short time, and that could be part of the hidden plumbing
that's handled automatically.

I'd expect people to do most of their development in RAM and only D/L
to flash when their code is mostly done and tested. I think the DP256
only has 100 flash programming cycles specified in the spec sheet (I
don't remember exactly). I think you can expect a lot more than that
at room temperature, but it's still not something you want to do
constantly. Newer devices are spec'ed for 10,000 cycles and can
probably give a lot more than that.

> It doesn't make sense what you said about puting vectors in EEPROM.
> With DBug12 present, IRQs are forwarded to the 0x3c00 table in RAM.

That's right, but why can't you save your vectors in EEPROM and copy
them to RAM when d-bug12 executes the jump-to-eeprom? D-bug12 will
indeed have first crack at the interupts, but then it would pass them
to the addresses stored in the RAM table which we already setup.

The end result should be exactly what is expected: you keep d-bug12,
and you have the choice of D/L'ing your code to either RAM or flash
(along with the plumbing that includes EEPROM, but that could be
transparent), and when you flip the switch you can run your program
automatically upon power-up or reset.

Futhermore, you could debug your program from flash or RAM, including
the use of breakpoints (2 in the case of the DP256). And this would
use a visual debugger, and not a text-mode interface (like d-bug12 or
gdb). My C language support isn't done yet, but it's coming as time
allows.

And you get all this with only a single serial connection between the
EVB and the PC. And most people who would want to use this already
have that hardware and a PC.

Eric



(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )

At 04:12 PM 10/13/2006, Eric Engler wrote:
>I'm not sure if the DP256 allows erasing only part of the flash (do
>they let you erase only 1 bank at a time?),

You have the options of erasing all flash banks (some of the Freescale
documentation calls them "arrays"), a selected flash bank, or an individual
sector (512 bytes, for a MC9S12DP256, different for some other parts).

As each bank has its own controller, mass erasing all 4 banks at once takes
the same time as a mass erase of 1 bank. A single sector erase is faster
than a mass erase, but erasing an entire bank with sector erases takes much
longer than a mass erase.

Setting protection on a flash area prevents mass erases of that bank, and
sector erase of the protected area, but not other areas.

In principle, you can use protection to keep your bootstrap and debugging
code in flash forever while reprogramming your developing application
repeatedly.

>but if not, it's still not hard to re-program d-bug12 using the serial
>monitor at 115K. It should only take a short time, and that could be part
>of the hidden plumbing that's handled automatically.
>
>I'd expect people to do most of their development in RAM and only D/L
>to flash when their code is mostly done and tested. I think the DP256
>only has 100 flash programming cycles specified in the spec sheet (I
>don't remember exactly). I think you can expect a lot more than that at
>room temperature, but it's still not something you want to do constantly.

The 100 erase-write cycle number is for the entire temperature range. In
recent documentation Freescale has claimed typical endurance of >1000
erase-write cycles at room temperature.

There have been very few reports of failures, and several reports of well
over 1000 erase-write cycles with no failures.

1000 erase-write cycles corresponds to every 2 hours for a normal working
year (2000 hours). That's pretty intense coding. As a business
proposition replacing a $20 part every year isn't a major expense.

However, the big advantage of debugging in RAM is that you have unlimited
breakpoints, rather than the 2 hardware breakpoints available for flash
debugging on the MC9S12DP256.

Steve Russell
Nohau Emulators

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of 68hc12 -- send a blank email to 68hc12-subscribe@yahoogroups.com )