8-bit MicrocontrollersのトピックRe: HCS08 firmware update on CAN

HCS08 firmware update on CAN

Simone — Thu, 04 Oct 2007 18:52:26 GMT

Hello everyone!
I'm working on the new DZ60 uC, and what I'm searching is a way to remotely update its firmware.
I've made some research on the net and in the forum, and I've found something interesting about it (AN2140, TN228, TN235; I attached them for your convenience).
From what I know at the moment, it's possible to run a routine in Ram in order to erase or reprogram the flash, but my ideas are still a little confused.
What I have in mind is to update the firmware (i.e. reprogram it in part or entirely), "downloading" the new firmware by CAN.
I have a system composed by many different parts connected on a CAN bus; the goal is to permit the update of any part simply plugging an SD card, containing the firmware files, into the motherboard. The motherboard reads the data on the SD and transfer them to the appropriate target device on the CAN bus. At this point the target should be able to read the data and auto-update its firmware... and that's the crucial point!

- If I complete the transfer of the new firmware, copy it in ram, and then erase/reprogram the flash I don't need to move in Ram the code to use the Mscan and to manage the interrupts on CAN receive, but I think that probably the entire firmware won't fit into the Ram.
- If I move in Ram the code to manage Mscan I won't have the last problem since the firmware is received and written 8 bytes at the time, but there is the backside that if for some reason there is a problem on the CAN transmission, the process will stop and my device will be lost.

Do you have any idea or suggestion?

Simone

TN235.pdf

AN2140.pdf

TN228.pdf

Message Edited by t.dowe on 2009-09-24 03:06 PM

Re: HCS08 firmware update on CAN

celsoken — Thu, 04 Oct 2007 21:20:34 GMT

I am not a DZ60 expert, neither I have an idea on what kinda hardware you're working with, but I have two suggestions:

- if you can add extra USD, place a small serial flash to hold all your 64Kbyte update, use CAN to fill it, block sanilty check, and your ram to xfer code;

- second option (if you can't do the first one), make a small and permanent CAN based bootloader, protect the area, use part of your ram to xfer sectors (768), use doonstack or similar functions to erase/program flash. Take good care with your vectors, and validate all blocks of code before transferring control. Durty job, but it works.

Good luck,

Celso

Re: HCS08 firmware update on CAN

bigmac — Thu, 04 Oct 2007 21:51:51 GMT

Hello Simone,

It would seem you require a "bootloader" facility that uses CAN for communications, rather than the usual SCI. The bootloader code would be located in protected flash, and would never be erased. This means that communications can always be retained. Of course, this code could never be updated, except by means of BDM.

I assume the required process would be to upload enough of the new code to completely fill a sector (768 bytes), to a suitable RAM buffer. To erase and reprogram each sector, one at a time, would require a small amount of code to be transferred to the stack, and executed from there, at times when the flash memory is inaccessible. For the sector erase period (20ms), you will need to take into account that communications will be disabled.

To allow for loss of communications, and failure of the process, or even loss of power, you would need to devise a scheme where the successfull reprogramming of each sector is flagged in a special control sector. At the start of the reprogramming procedure, this sector could be the first one erased (but not programmed at this point), to flag that bootloader mode is now required. Then, as each new sector is erased, reprogrammed, and verified, a byte within the control sector, to represent the newly reprogrammed sector, could then be programmed with a value other than 0xFF. Only when the last sector for the new firmware is reprogrammed would operation switch to the new code.

Regards,

Mac

Re: HCS08 firmware update on CAN

Simone — Thu, 04 Oct 2007 22:22:51 GMT

Firstly, thanks for your reply. The situation is getting clearer to me, but I still have some doubts...
Please tell me if I have well understood:
The bootloader will reside in protected flash, so it will be always available. On startup the bootloader is called, and it checks the control sector bytes; if they are all 0xFF it starts the "main" routine jumping at the right location in non-protected flash, otherwise it waits for CAN messages to download data (maybe sending signals on CAN bus of his state of "please give me my firmware I'm hungry... ). On the reception of the update request on CAN bus the program writes 0xFF to control sector bytes and then reset.

If till now I'm right, I have a few questions: in which way I enter the bootloader routine during normal operation? Can I reset the device with a CAN message?
In order to prevent the "master" sending messages when the "slave" is writing to flash, would it be better to enable a sort of protocol, in which the master send the first message with the update request, then the slave (now in boot mode) asks the download parameters (such as number of sector to write etc...), and subsequently asks for single sector trasfer?

Simone

Re: HCS08 firmware update on CAN

Simone — Thu, 04 Oct 2007 22:27:30 GMT

Ops...I made a little confusion with 0xFF...but I think that what I did mean is clear nevertheless....

Simone

Re: HCS08 firmware update on CAN

allawtterb — Thu, 04 Oct 2007 23:07:40 GMT

I don't think it is necessary to run the flash writing from the stack, I believe that in the DZ60 flash can be written from flash.

Re: HCS08 firmware update on CAN

bigmac — Thu, 04 Oct 2007 23:42:07 GMT

Hello Simone,

Firstly, I should say that I am not familiar with CAN and its operational and timing limitations. Others will need to advise on these issues.

Simone wrote:
The bootloader will reside in protected flash, so it will be always available. On startup the bootloader is called, and it checks the control sector bytes; if they are all 0xFF it starts the "main" routine jumping at the right location in non-protected flash, otherwise it waits for CAN messages to download data (maybe sending signals on CAN bus of his state . . . On the reception of the update request on CAN bus the program writes 0xFF to control sector bytes and then reset.

Your understanding is basically correct. You might arrange that one of the bytes in the control sector is a "programming complete" flag. This way, the reset procedure would need to test only a single byte to determine if bootloader mode should be entered. Perhaps you should also allow for a CAN message (within normal program operation) to cause entry to bootloader mode, so that the master can initiate the reprogramming process. To indicate a programmed sector, I might choose a value of 0x00.

. . . in which way I enter the bootloader routine during normal operation? Can I reset the device with a CAN message?
In order to prevent the "master" sending messages when the "slave" is writing to flash, would it be better to enable a sort of protocol, in which the master send the first message with the update request, then the slave (now in boot mode) asks the download parameters (such as number of sector to write etc...), and subsequently asks for single sector trasfer?

Allocate a CAN message for entry to bootloader, as mentioned above. Yes, you will need a protocol that is compatible with the operation of CAN. The master should have total control over the reprogramming process, including the current sector to be erased and programmed. It should also be able to determine which sectors have already been programmed, and those sectors that still need to be programmed, by reading the relevant bytes from the control sector. Only the master "knows" how many sectors will be occupied by the new firmware.

This way the master can ensure that all sectors have been correctly programmed prior to finally writing the "programming complete" byte.

Regards,

Mac

Re: HCS08 firmware update on CAN

rocco — Fri, 05 Oct 2007 09:38:41 GMT

An alternative to Mac's "control-sector" technique is to use a firmware checksum.

I don't use CAN, but my bootloader does re-program the flash on devices along an RS485 bus.

What I do in my firmware startup routine is to compute a checksum on the entire flash. I then compare it with a stored checksum in the last two bytes of flash. If the compare fails, I jump straight into the bootstrap firmware. I can also enter the bootstrap firmware by sending a command down the RS485 bus.

When reprogramming a device, the host controller sends the firmware to the device one page at a time, and waits for an ACK that says that the page has been programmed and verified. It sends the new checksum for programming as the final operation. This way, if programming is ever interrupted, the checksum will be incorrect and the bootstrap routine will be entered automatically upon reset.

There are several disadvantages to this approach over Mac's approach. With Mac's technique, if programming is interrupted, the control-sector tells you where to continue programming. This can be a big advantage if communications are poor, since you don't need to start programming from the beginning after each failure, and the job will get done eventually.

Also, checking the control-sector at startup will be fast, whereas computing the checksum for all of flash will not. You can count on the checksum routine adding a bunch of milliseconds to your startup.

An advantage of the checksum is that it is pretty simple to implement (which is why I use it). Another advantage is that the bootstrap will be run automatically upon reset if the flash gets corrupted.

Re: HCS08 firmware update on CAN

Simone — Fri, 05 Oct 2007 14:00:30 GMT

A little delay on startup is not critical for my application; however, I'll try both the check methods to see which suits best the job.

If it's not a problem for you, can you show me your bootloader code? I'm not familiar with assembler and I feel a little disoriented.

Thanks again,

Simone

Re: HCS08 firmware update on CAN

rocco — Fri, 05 Oct 2007 15:37:20 GMT

Hi Simone,

Here is the code. It is a modified version of AN2295, which uses the serial port. This one is configured for the 908GP32.

If you have any questions, let me know. You may need some macro definitions.

Re: HCS08 firmware update on CAN

Simone — Mon, 08 Oct 2007 16:04:28 GMT

Hi Rocco!

I'm trying to integrate your code into my application; assembler is not so awful as it may seem at the first glance! I'm just messing around with the register porting from GP32 to DZ60.

I need some macro declaration, like you said last time (INIT, INIT_BOOT, RESET); in addition, there is one thing I can't understand: the compiler tells me "Forward reference not allowed" in this instruction "LEN: equ RAM_+1".

Thanks!

Simone

Re: HCS08 firmware update on CAN

Simone — Tue, 09 Oct 2007 14:24:41 GMT

Ok, I finally managed to have my code working!

I'm able to write and erase the flash; for now I send a simple byte on SCI adn write it at a fixed location. Now I'll develope the rest of the application. I'm also looking for a way to integrate asm and C; now the bootloader is entirely in assembly, but the rest of my application is in C, so if exist a way to "merge" the two parts it will be very helpful.

Thank you all very much for your help!

Simone

Re: HCS08 firmware update on CAN

bigmac — Tue, 09 Oct 2007 22:02:29 GMT

Hello Simone,

When you create the project, using the new project wizard, you will need to specify that you require both C and assembly within the project. I would assume that you would use relocatable assembly code, so that the linker can organize the various sections of code.

If you need to call assembly routines from within your C code, any parameters passed will need to conform with C parameter passing rules.

This assumes that there would be separate .ASM files for the assembly code. You may also use inline assembly within a .C file.

Regards,

Mac

Re: HCS08 firmware update on CAN

Simone — Fri, 12 Oct 2007 20:15:15 GMT

Finally I got it!

The CAN bootloader is a reality.

If someone is interested I can post the source. I still have to reorder it because it's still a mess, but it works.

Simone

Re: HCS08 firmware update on CAN

Alban — Mon, 15 Oct 2007 17:55:03 GMT

Hello Simone,

That would be a great idea !!!

Cheers,
Alban.

Re: HCS08 firmware update on CAN

Simone — Mon, 15 Oct 2007 22:57:05 GMT

Hi Alban,

I post here my source code, please move it in another thread if you think that so it will be more visible.

The code is in part developed from Rocco's source; it implements a selectable RS232-CAN bootloader which resides in protected memory. It's all except perfect, especially in the asm part (I'm nothing more than a rookie in assembler); if you have any advice it will be well accepted.

At startup it checks the flash (sum and xor); if it's ok it jump to the normal "_entrypoint" of the application, otherwise it enter the boot mode and waits for incoming messages. The external application has the ability to write, erase and read the flash, plus some other little options (reboot, read firmware ID...). For now I tested it with an external application in VB, and I'm able to reprogram the firmware via both rs232 and CAN.

The .asm file contains the low-low level initial check, and the init to start the essential functions of the micro, including obviously FLASH, SCI and CAN. The clock is given by an external 4MHz oscillator, requested by the tight timing tolerance of CAN controller. I then enabled the protection of last 3K of flash, and redirection of vector table.

The main loop waits for incoming messages in a polling fashion.

The .prm file contains the memory allocation for the bootloader: I put it in PROTECTED_ROM section. All the bootloader is in protected rom (0xF400-0xFFB0); please note that I didn't manage to put the .asm code in a relocatable section, so I had to assign it at address 0xF800 by mean of a ORG directive.

An important thing is where you place the "_EntryPoint" of the normal application in the non protected rom. It MUST be always in the same location to allow the bootloader to jump to it. I did this allocating the "_EntryPoint" function in MY_ENTRYPOINT.

Then I added here the code to automatically write the SUM and XOR in the right locations. Finally, note the entry point of the application (bootEntry). This, along with the reset interrupt vector, should point to label "bootEntry" in the asm file.

The .c file contains the routine to manage the CAN messages. I wrote them in C because I found it less difficult. Please pay attention to double check your code when you modify the C code; infact the compiler can try to optimize your code calling some low-level library function, which resides in non-protected rom! It result in application crashing when it runs!! To check if the compiler has used the library you have to look in the .map file. An example is visible in the code, where there are the splitted "switch" instructions: I had to split it because if it's all in one it requires a library function (try it to see).

If you have questions, or if I wasn't clear enough, feel free to ask!

Simone

Re: HCS08 firmware update on CAN

ohanica — Fri, 16 Nov 2007 00:02:44 GMT

Hello Simone,

very nice project! seems to be a very basic working example which is really a nice thing for newbies to (CAN-)bootloaders, like I am.
Could you post your complete (CW-)project, so it should be possible to get it working on a DZ60-test-platform and much more easily understand everything, where code is written, how it is organized on the PC and then in uC-memory.

How do you flash down the s19 file of your main application via CAN when the bootloader is installed already? What kind of PC-software/hardware do you use for "CAN-flashing"?

many thanks and regards,
Johannes

Message Edited by ohanica on 2007-11-15 04:03 PM

Re: HCS08 firmware update on CAN

Simone — Fri, 16 Nov 2007 19:48:49 GMT

Hello Johannes!

Glad to hear that someone find it interesting. Maybe someone will put it into an application note...

Here it is the complete sample project (please change it's extension to .rar). It's based on the DZ60 demo board (DEMO9S08DZ60) so it should be simple enough to understand. The program do not really do anything of complex...it just flashes two leds.

For testing purposes I have written a Visual Basic program that takes the .s19 and send the appropriate command (via CAN) to the bootloader (it send the "Reset and enter boot mode" command too, while in normal mode). The CAN interface is a PCI based card from Trinamic (CANNes); the vb software is based on drivers made for this card, so it should be useless without it.

Now I'm working on the other part of the project, the implementation of a "FAT32 compatible"-"SD Card" reader for the micro that acts as master. In this way I'll be able to put the .s19 file on a SD and download it to the bootloader without a pc.

I know it's quite a big problem to send a complete .s19 file if you have no PC to CAN interface; if you have one I can send you my vb program so you can adapt it to your hardware.

Bye!

Simone

2ProvaFwUpdate.jpg

Message Edited by t.dowe on 2009-10-27 12:27 PM

Re: HCS08 firmware update on CAN

ohanica — Thu, 29 Oct 2020 08:56:33 GMT

Hello Simone,

first of all many thanks for posting your coplete project. Seems very interesting and it did help me a lot in understanding and learning about CAN-bootloader from practical point of view. I still have a little issue I don't know how to solve: The project doesn't build, it tells me

Code:

Error   : C5200: non_bank.sgm file not foundStart08.c line 31  Error   : Compile failed

This has something to do with the Processor Expert, but I didn't manage to sole this issue up to now.

One more question: where did you get your CANnes Card? How much does it cost (approx.)?

greetx,
Johannes

Re: HCS08 firmware update on CAN

Simone — Thu, 29 Oct 2020 08:56:35 GMT

Hello!

I don't know exactly how much it costs, because it was here since before I started working in my office. I think it should be around 200$. The link is: http://www.trinamic.com/tmc/render.php?sess_pid=216. For testing purpose maybe you will find other interfaces (i.e. CAN-USB) that can be even more useful.

For the problem you find, maybe it's for the different version of CW used. For my project I used CodeWarrior 6.0 (in the "about" it tells 5.9.0 - quite confusing). However, I search for the file you are missing; it contains only this lines of code:

Code:

#if defined (__BANKED__)#pragma CODE_SEG __NEAR_SEG NON_BANKED#endif

Try to create a "non_bank.sgm" file and insert those lines in it. It should work now. Let me know if it ask for some more files.

Bye!

Simone