-
-
Notifications
You must be signed in to change notification settings - Fork 638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CANOpen firmware update #111
Comments
I can't really speak to your first point since I have not worked extensively with any bootloaders. But CiA 814 seems to just define a few common sense checks like "make sure you are writing the the device you think you are" After skimming CiA 417 I do not think it is merely a recommendation. CiA 417 specifically states when something is out of the scope of the document and up to the end user (like the node-ID assignment section). That logically supports the rest of the document, and by extension CiA 814, being not just a recommendation. If I was to pick a standard to follow it would certainly be the one suggested by CiA. As to your last point, I think adding a bootloader feature to CANopenNode would be out of the scope of the project. It would make more sense for an existing bootloader project to support CANopen, and thus use CANopenNode. |
Thanks for the heads up. Regarding the latter, that's correct, I would think the same, off course its not about simply adding CANOpenNode to an existing bootloader. Most of the time you would want a minimal version of that stack as the bootloader is always kept very compact. Because there is also the application and it all has to fit you internal flash. The binary size optimizations is just one thing though, which would not always be required. What puzzles me the most is what is required to 'download' the firmware. What is already in the stack, and what needs to be added. The latter is the most important, since you could go with whatever bootloader you'd want: either one with minimal CANopen stack, or an even more basic bootloader that does only the verification / flashing. |
Hi,
I've used the bootloader implementation from
https://github.com/kcaluwae/dspic33e-bootloader on PIC24s that i've done
and got it working fine but not deployed to production. The basic
requirement is to upload via SDO to 0x1F50/0x01. You can fit that boot
loader in the first few pages of a PIC24 flash then after a timeout or a
NMT command it jumps to the main application with the CanOpenNode stack.
0x1f50 is pretty standard for this kind of thing, also see
https://www.systec-electronic.com/fileadmin/Redakteur/Unternehmen/Support/Downloadbereich/Handbuecher/CANopen-BootloaderSoftware_Manual_L-1112e_05.pdf
for other implementations of canopen bootloaders again using the 0x1f50
objects + others to complete the flash.
There is also a implementation of the flash loader tool built in to my
canopenmonitor software https://github.com/robincornelius/CanOpenMonitor in
the flasher plugin which i've tested against the first implementation and
can load mplab hex files on to pic24s via canopen.
Robin
…On Thu, 10 Oct 2019 at 19:36, Geoffrey Van Landeghem < ***@***.***> wrote:
Thanks for the heads up.
Regarding the latter, that's correct, I would think the same, off course
its not about simply adding CANOpenNode to an existing bootloader. Most of
the time you would want a minimal version of that stack as the bootloader
is always kept very compact. Because there is also the application and it
all has to fit you internal flash. The binary size optimizations is just
one thing though, which would not always be required. What puzzles me the
most is what is required to 'download' the firmware. What is already in the
stack, and what needs to be added. The latter is the most important, since
you could go with whatever bootloader you'd want: either one with minimal
CANopen stack, or an even more basic bootloader that does only the
verification / flashing.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#111?email_source=notifications&email_token=AABG2GEFVHNSVOJYYNQPSZ3QN5Y4HA5CNFSM4I7ODUY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEA5K7MY#issuecomment-540716979>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABG2GGBZZHGDZU7LPRVY2TQN5Y4HANCNFSM4I7ODUYQ>
.
|
Hi, Firmware update is specified in DSP 302-3. This is quite comprehensive and gives a flowchart how updating is supposed to work and the OD entries you have to implement. 0x1F50/0x01 is just one of them. CiA 814/417 is for lifts, so you can't rely on that to be implemented in anything else. I've used CANopenNode for our bootloader too, but with everything removed except what ist absolute necessary and SDO block download (to make it faster...). This way, I was able to get the entire bootloader with flashing and some features in ~12kB STM32/GCC ARM. |
@martinwag I'm curious about how the node IDs, baud settings, etc. are handled for the bootloader--is there a completely separate object dictionary for the bootloader? I haven't had a chance to try it out yet, but one of the major limitations that I've noticed with the stock STM32 CAN bootloader is that it only supports one node at a time. It seems like the ideal solution from the end-application perspective would be for the bootloader to use the same configuration settings as the application for the baud,node ID, etc. so that you could update FW after the device is in a completed system (possibly with multiple other devices with the same CANopenNode bootloader). Can't help but feel a bit uneasy though blurring the lines between the bootloader and application code. Putting the device into bootloader mode and changing the settings via SDO is an option, but that adds a process step that wouldn't always be necessary (and thus easy to overlook). Anything you can share on this would be appreciated. In general, having a standardized/template for a CANopenNode bootloader implementation that could be tailored for individual platforms would be a great resource. |
Hi, Yes, I have a completely separate OD for the bootloader. This way, I can ensure that all our devices share the same OD inside bootlaoder (actually the entire bootloader...) and distributing/preprogramming/updating the bootloader is simple. You already need to pass the information "bootloader requested" from your firmware to bootloader. Just add node ID, baud rate and so on to that block. |
Thanks for the feedback. In between other things I've had some time to experiment with object 1F50h.
The OD has following changes:
This way I can download 1024 bytes:
The download handler implementation is just for testing purposes. In my case the bootloader only swaps applications, the downloading is handled by the application. |
In the end I've completely moved the implementation from CANopenNode library into the application as it currently makes good sense. The data handling and writing to storage device is just very application specific. My demo application can be found here. In my case I'll use a generic bootloader that handles the new firmware file, instead of creating a CANOpen bootloader. The demo application auto restarts after the download has finished. As I have noticed in CiA814, the flow is a bit different in that master decides to reboot the node. My final application will try to do that. |
I am aware this is an old and closed thread. |
I don't have experience with bootloader, but I think, this may be relevant from v4: |
OK, thank you for your answer
…---Original---
From: ***@***.***>
Date: Mon, Jul 5, 2021 17:24 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [CANopenNode/CANopenNode] CANOpen firmware update (#111)
I don't have experience with bootloader, but I think, this may be relevant from v4:
https://github.com/CANopenNode/CANopenDemo/blob/master/demo/domainDemo.c
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I think I see how to do this with the domain example. |
You can use cocomm, where SDO client is already implemented. If you like to make own SDO client - that is advanced topic... |
One of the specific features I've been looking at is that of applying firmware updates.
There are some ways to do that. Most imply having a separated bootloader and application. The bootloader's task is that it verifies applies the firmware update. Apply the bootloader is either enabling another partition, or effectively writing the new application over the older one.
Sometimes the application fetches the firmware update candidate, sometimes that task is up to the bootloader using some kind of minimal CANOpen implementation.
Both have their pro's and con's but that is not what I would like to discuss.
I've noticed the CiA paper 814:
Part of the paper describes from a user point of view the functionality of applying fwupdates over CANOpen through the bootloader. So some question come to mind:
The text was updated successfully, but these errors were encountered: