J1939 firmware update - Parallel programming

[matb]

Bonjour everyone,
I have a project where I will have multiple devices wired on the same J1939 CanBus.
The microcontroller is not yet chosen but will be a Microchip one (either dsPIC33EP256MU806 or PIC18FxxK80 i guess).

I'm seeking advice from a bootloader point of view, what would be really cool (but I don't know if feasable and accepted in J1939 standard) is to be able to reprogram 1 or multiple devices at the same time with the on-board CanBus.
Have you guys did something like this before ? Is it a big no-no standard wise, do I have to unwire the device and do the updates out of bus ?
J1939 is using extended frames only so I guess I could use standard frames as to not make something run on other ECUs while I'm programming a device ?

Also seeking documents to better understand bootloaders as it will be the first one I ever build (and with no direct supervisor that can help except internet strangers

[darkspr1te]

Bonjour everyone,
I have a project where I will have multiple devices wired on the same J1939 CanBus.
The microcontroller is not yet chosen but will be a Microchip one (either dsPIC33EP256MU806 or PIC18FxxK80 i guess).

I'm seeking advice from a bootloader point of view, what would be really cool (but I don't know if feasable and accepted in J1939 standard) is to be able to reprogram 1 or multiple devices at the same time with the on-board CanBus.
Have you guys did something like this before ? Is it a big no-no standard wise, do I have to unwire the device and do the updates out of bus ?
J1939 is using extended frames only so I guess I could use standard frames as to not make something run on other ECUs while I'm programming a device ?

Also seeking documents to better understand bootloaders as it will be the first one I ever build (and with no direct supervisor that can help except internet strangers

i've written many bootloaders from amiga to stm32fxxx and beyond. I've learnt that you dont always have to reinvent the wheel there are already bootloaders for both supporting CANBUS that can guide you, also writing a bootloader is a good tech-ercise as you learn how to setup the hardware to be in a position to function. this si where you learn all the bit-fields and subtle parts of the device.
I've not looked at the j1939 standard fully myself but i would assume there is a accepted mechanism for triggering a device firmware update for emissions updates , i know the j2435 standard does have it.



darkspr1te

[matb]

Thanks for the reply.

[...]I've learnt that you dont always have to reinvent the wheel there are already bootloaders for both supporting CANBUS that can guide you[...]

I looked but Google doesn't seem to yield any results, do you have links of exemples or alike. I guess this is very industry oriented so the hobbyist doesn't have "open source" exemples.
I found 2 application notes from Microchip AN247 http://www.t-es-t.hu/download/microchip/an247a.pdf and AN851 https://ww1.microchip.com/downloads/en/appnotes/00851b.pdf and some people mention EZBL https://www.microchip.com/SWLibraryWeb/product.aspx?product=Microchip%20Easy%20Bootloader but it seems to be discontinued for the Harmony code generator ?

I looked more deeply in the J1939 and there are Manufacturer identifiers so I guess I could use a couple of IDs there for each device on the network ? https://copperhilltech.com/blog/design-of-proprietary-parameter-group-numbers-pgns/

[Jeroen3]

I made one. CAN bus is really slow to transfer lots of data. So I thought it was a good idea.
It was Meh, you transfer sector by sector and require an ack from each node. With enough devices >4 there was always one that missed a frame because you want high speed an non-ideal temporary bus wiring, and required a re-do of the sector.

Also, many CAN-USB devices can't do full bus speed. Had to buy and test a few, settled on kvaser eventually.

In the end it was Meh, wouldn't do it again. Just make it so you don't need to update the software that often.

Also if I recall correctly j1939 doesn't have an bootloader transfer protocol big enough for large images iirc. But you could use proprietary pgn's for that.

J1939 also has a limit on the repetition speed of messages, severely limiting how fast you can go.

[NorthGuy]

I have a project where I will have multiple devices wired on the same J1939 CanBus.
The microcontroller is not yet chosen but will be a Microchip one (either dsPIC33EP256MU806 or PIC18FxxK80 i guess).

CAN bootloader is a very common thing.

You can use one of the newer dsPIC33CKxxxxx devices. They have CAN FD. They also can be partitioned - one partition runs, the other can be updated by the bootloader at the same time. Once updated, partitions can be swapped by hardware.

[matb]

@Jeroen3
Nice to know there exists some. Yes I guess missed frame will be to expect.
For CAN-USB I have Ixxat it's works ok.

Just make it so you don't need to update the software that often.

That would be cool but it is required from the client so

J1939 also has a limit on the repetition speed of messages, severely limiting how fast you can go.

I read some kind of 4% if I remember correctly but I guess at one point you have things to do, like the update at 4% will take an hour so they may as well disgress from that rule.

@NorthGuy

They also can be partitioned - one partition runs, the other can be updated by the bootloader at the same time. Once updated, partitions can be swapped by hardware.

I will have to read about these dsPIC33CK to see, haven't read anything what would be the point we can already do that ?

[8goran8]

Some variants of PIC24 and dsPIC33 have Dual Partition Flash and Live Update features.
You can find more information here:

http://ww1.microchip.com/downloads/en/DeviceDoc/70005156b.pdf

[matb]

@8goran8 and @NorthGuy thanks for the informations, I didn't know that it existed, it's kind of cool.
But I think I don't need this kind of features just a bootloader but it's nice to have this product in mind

[NorthGuy]

@8goran8 and @NorthGuy thanks for the informations, I didn't know that it existed, it's kind of cool.
But I think I don't need this kind of features just a bootloader but it's nice to have this product in mind

Partitioning makes the bootloader simpler, easier to develop, and more reliable. It removes all the restrictions the bootloader imposes on the application and eliminates the need to adjust the application for use with bootloader. It also makes the bootloader more powerful - it now can update everything - config bits, IVT, can even update the bootloader itself.

[matb]

Thanks I will keep that in mind when I choose the µC.
Can someone point me some bootloader litterature so I can better understand how it is supposed to work ?

Like you have a specific ID then you write like :

• d0 = address
• d1 → d7 hex data (from .hex ?)

no CRC since it is CAN-BUS.

Basically there are multiple messages like Erase, Write, Read, Acknowledge and Verify.

Erase the application memory space, Write data to specific address, Read bootloader and App version, Acknowledge to tell received / good or not received / bad, Verify () what am I supposed to verify some kind of memory CRC ?

[8goran8]

Microchip Application Notes
AN247 - A CAN Bootloader for PIC18F CAN Microcontrollers
AN1157 - A Serial Bootloader for PIC24F Devices
AN1094 - Bootloader for dsPIC30F/33F and PIC24F/24H Devices
AN851 - A FLASH Bootloader for PIC16 and PIC18 Devices
Bootloader Generator User’s Guide

[matb]

Thanks I will have a look, I had already found AN247 which is discountinued because of bugs.
AN851 looks promising, the only problem is that it is in assembler but I guess I can rewrite that in C easily. Seems strange that there are no updates on the given firmwares since 2002 ?

I guess there are no "ready-made" can-bus bootloader but that's ok now I have good documentation and a general architecture in mind.

[Jeroen3]

There are a few ready-made CAN bus bootloaders that you can buy.

But the concept doesn't have to be very hard. It's only moving data around, you can do it stateless if you want.
1: control byte
2-4: address
5-8: data
Then just many more of those messages.

However, one-to-many programming requires session management. That's where things might get complicated.

[eutectique]

Bonjour everyone,

Salut!

I'm seeking advice from a bootloader point of view, what would be really cool (but I don't know if feasable and accepted in J1939 standard) is to be able to reprogram 1 or multiple devices at the same time with the on-board CanBus.
Have you guys did something like this before ?

Many times.

Usually, firmware updates are done with UDS. We are talking in broad automotive sense. You can equally think of material handling or construction equipment.

At power-up, a device sends the boot frame to identify itself, and if no one starts a UDS session during some grace period (say, 100..300 ms) it boots into the application which might use J1939 (it might use UDS as well).  If a session is started, your bootloader should handle write and read requests to update the firmware.

Here are some links to let you know the scale of the disaster: 

https://nvdungx.github.io/unified-diagnostic-protocol-overview
https://udsoncan.readthedocs.io/en/latest/udsoncan/intro.html
https://www.emotas.de/en/bootloader/uds-bootloader
https://www.csselectronics.com/pages/uds-protocol-tutorial-unified-diagnostic-services
https://www.sontheim-industrie-elektronik.de/en/expertise/standards/protocols/uds-iso-14229/
https://piembsystech.com/uds-protocol/

And to answer your specific question about parallel programming, it could be done in principle, but the complexity of the bootloader does not worth it.