• AVR Freaks

Hot!CAN Bootloader

Page: 12 > Showing page 1 of 2
Author
ASICAlex
Starting Member
  • Total Posts : 43
  • Reward points : 0
  • Joined: 2018/02/27 15:40:02
  • Location: 0
  • Status: offline
2019/03/01 15:49:55 (permalink)
0

CAN Bootloader

I am needing a CAN bootloader for my dsPIC33EP256MU806.  I am fairly new to dsPICs (and PICs in general), but looks like the dsPIC33EP does not have any bootloader in its flash "from the factory".  Instead of trying to figure out how to create some code with minimal CAN function to be able to receive data and program the flash, I have found one on github, and I think I will try it out.  For some reason I cannot post the link, as it gives me permission error when I try to post, but a google search of "bootloader dsPIC33E" it will be first result. (How do I get around this? Can I post html links here?)
 
Has anyone used this, and what was your experience?  Seems like it is a good option.
#1

26 Replies Related Threads

    NKurzman
    A Guy on the Net
    • Total Posts : 17723
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/01 19:39:18 (permalink)
    0
    Ok.  Thanks.  Yeah I saw the EZBL too, so its a matter of which one would be easier to get running.  I will dig into the EZBL to see how hard it would be to change it to CAN interface instead of USB/UART.  The CAN bootloader on github looks pretty good too, but I am not super familiar with CANOpen, and I can see trying to get the host application taking a little bit.  But I think those two options would be the best to explore.  If someone has had any experience with either using CAN, let me know which worked best for you!
    #3
    NKurzman
    A Guy on the Net
    • Total Posts : 17723
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: CAN Bootloader 2019/03/01 20:01:52 (permalink)
    0
    What CAN Bus are you targeting? There are a Lot of CAN Protocols.
    You will Need a PC CAN Adapter and the PC program that works with it.
    #4
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/01 21:33:36 (permalink)
    0
    I have the CAN bus running pretty well right now.  To get started I actually just used an MCLV2 eval board to send CAN messages to my actual board.  I would type in the CAN commands via UART to the MCLV2 board, and it would send/receive CAN messages to the prototype board. Most of these messages are just custom commands that perform a task.  We also will be using some of the Vector tools like CANalyzer and CANape for communication.  Besides "normal" CAN commands (to perform systems tasks), there will be an XCP driver and other protocols.  Might be able to use the Vector tools if I go with the github CAN bootloader that uses CANopen.  We see. 
    #5
    Stampede
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2006/10/04 05:59:28
    • Location: Germany
    • Status: offline
    Re: CAN Bootloader 2019/03/14 15:48:49 (permalink)
    0
    I added a CAN driver to the EZBL, wasnt too difficult. Just need to fill the data of the CAN messages into the ezbl FIFO and it will do the rest for you. I wrote a lillte QT app to replace that weird Microchip tool, uses peak can and vector products.
    I added a very simple XCP driver, but the problem is that XC16 doenst produce ELF files that can be read by CANApe, because it's not cpompliant with the ELF/DWARF standard.
    #6
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/14 16:03:37 (permalink)
    0
    Ok!! So I can look into modifying the EZBL.  What is a "QT" app and what Microchip tool was it replacing?  I assume this QT app allowed you to send the new firmware image over CAN.  This is something else I will need to figure out : software to be able to send the new firmware image over CAN using the PEAK or Vector CAN to USB adapters. 
     
    Were you able to use your XCP driver?  I have not really started work on this yet, but I do have the free Vector XCP driver I was going to integrate into my code.  I have not worked with XCP before, but CANape parses the ELF file to get the memory locations of variables for calibration and monitoring, correct? So with this dsPIC33EP256Mu806 and XC16, this will not be possible? We are not going to have a huge number of items to calibrate and monitor, I guess we could setup our A2L files manually?
     
    Sounds like you have already done many things that we will be doing on this project.  I would love to get some more details. 
    #7
    Stampede
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2006/10/04 05:59:28
    • Location: Germany
    • Status: offline
    Re: CAN Bootloader 2019/03/14 16:21:24 (permalink)
    5 (1)
    Concerning the QT app, it's just a little c++ project created with the QT framework. It parses the BLOB file created by ezbl and sends it to the dsPIC using either PEAK CAN oder Vector CAN adaptors.
    I also used the free Vector XCP driver, which I connected to the CAN driver on the dsPIC. Acually, you just have to call the XCPCallback function once you received a CAN message, and provide a function to send a CAN message back. Thats all.
    Concerning CANApe and A2L, you need the a proper ELF file, the one the XC16 generates can't be read by any parser i found. The reason for that are some random 0x00, that can be found in the debug sections of the elf file. This will confuse the parser and you wont be able to extract any address or symbol. Thus, you need to remove those useless 0x00, see this thread: https://www.microchip.com/forums/FindPost/729290
     
     
    #8
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/14 17:17:56 (permalink)
    0
    Ok.  Thank you for all the great information.  I will for sure look into the "elf file issue" right now so we can be on top of it and when I get to the bootloader and XCP drivers I might ping you back.  I have just briefly looked at the Vector Free XCP driver, but it is encouraging that it may not be that bad. 
    #9
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/15 15:46:30 (permalink)
    0
    Stampede,
    I actually had the customer try to use CANape with the elf file and they are successfully able to grab the variables from it and create an A2L file.  Maybe microchip has fixed this issue?  I will have to find an elf parser to double check for myself.
     
     
    #10
    Stampede
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2006/10/04 05:59:28
    • Location: Germany
    • Status: offline
    Re: CAN Bootloader 2019/03/16 03:38:22 (permalink)
    0
    Hi Alex,
     
    that's very interesting news. I will have a look into that asap, at the moment I'm using the XC16 V1.35, which version do you use?
    #11
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/17 20:03:22 (permalink)
    0
    Same version.  I am just going by what they were saying in terms of importing the .elf into CANape.  Perhaps they were mistaken?
    #12
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/22 14:46:09 (permalink)
    0
    Stampede
    Concerning the QT app, it's just a little c++ project created with the QT framework. It parses the BLOB file created by ezbl and sends it to the dsPIC using either PEAK CAN oder Vector CAN adaptors.
    I also used the free Vector XCP driver, which I connected to the CAN driver on the dsPIC. Acually, you just have to call the XCPCallback function once you received a CAN message, and provide a function to send a CAN message back. Thats all.
    Concerning CANApe and A2L, you need the a proper ELF file, the one the XC16 generates can't be read by any parser i found. The reason for that are some random 0x00, that can be found in the debug sections of the elf file. This will confuse the parser and you wont be able to extract any address or symbol. Thus, you need to remove those useless 0x00, see this thread: https://www.microchip.com/forums/FindPost/729290
     
     You were right, the free XCP driver was not that bad to get integrated.  I am manually sending raw XCP packets to my ECU and seems to be working with the polling commands like SHORT UPLOAD, SET MTA and Download.  Other colleagues will be trying it with CANape soon.  Did you use DAQ lists for your implementation? I am trying to figure out how to implement these.  Whether CANape will somehow tell the driver what variables will be included in the ODT/DAQ lists or if I need to create these in the code.  I wish there were more examples online...




    #13
    Stampede
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2006/10/04 05:59:28
    • Location: Germany
    • Status: offline
    Re: CAN Bootloader 2019/03/23 01:58:12 (permalink)
    0
    Hi,
     
    I dont use the DAQ most of the time. IIRC, you need some to provide timestamps and run this XCPBackground task provided with the driver. And you should implement the "DisableInterrupts" and "EnableInterrupts" so you can send bigger blocks of data without the risk of having them corrupted beacuse of access by XCP and your useer program.
     
    ASICAlex
     You were right, the free XCP driver was not that bad to get integrated.  I am manually sending raw XCP packets to my ECU and seems to be working with the polling commands like SHORT UPLOAD, SET MTA and Download.  Other colleagues will be trying it with CANape soon.  Did you use DAQ lists for your implementation? I am trying to figure out how to implement these.  Whether CANape will somehow tell the driver what variables will be included in the ODT/DAQ lists or if I need to create these in the code.  I wish there were more examples online...

    If you only want to check data (e.g. of sensor, I2c data) or fine-tune parameters (e.g. control loops), the bare minimum setup is sufficent (using SET MTA and download/upload). DAQ and block commands a more or less just implemtentations to make the data flow more efficent (device initiated in DAQ and larger data block for commands to redice overhead).
     
    I checked again with XC16 V1.35, and it defintively creates that non-standard ELF files. Canape (V15 with ASAP2 V14) can "open" them, but won't find any symbols, variables, etc.
     
    Cheers
    Stefan
    post edited by Stampede - 2019/03/23 03:14:00
    #14
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/23 13:28:58 (permalink)
    0
    Hi Stefan,
    Thanks for the reply.  I just sent them code with the XCP driver integrated, so will know more in a few days how the elf file works, but sounds like it still might be an issue.  Our customer has all the Vector software so I have to wait for them to test it.  Though, I did download CANape and am running it in demo mode.  I ran the demo to see how they did all the DAQ setup (using ALLOC_ODT, SET_DAQ_PTR, WRITE_DAQ, etc) so I will be trying this to see if I can get the DAQ lists working.  Then I can decide if we want to use it and how much data we want to be able to send to the master.  To test out the XCP free driver, I am just manually sending XCP packets to my ECU.  I am using an mclv2 eval board as a UART to CAN bridge.  It has worked out pretty well. 
     
    Also, Microchip sent me a CAN bootloader, but I have not had a chance to look at it yet.  They advised against using the EZBL.  I will have to look at my emails to find the reason for this.  I think I could use my CAN bridge to test out the bootloader, but of course will have to figure out a better way of updating the code for the final product. 
    #15
    Stampede
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2006/10/04 05:59:28
    • Location: Germany
    • Status: offline
    Re: CAN Bootloader 2019/03/26 02:50:01 (permalink)
    0
    ASICAlex
    Also, Microchip sent me a CAN bootloader, but I have not had a chance to look at it yet.  They advised against using the EZBL.  I will have to look at my emails to find the reason for this.  I think I could use my CAN bridge to test out the bootloader, but of course will have to figure out a better way of updating the code for the final product. 




    Why would they advice against the ezbl? Definitively best free bootloader I've seen so far, and especially for CAN, as you can use multiple device on the same CAN bus using the same identifiers. What more to ask for?
    #16
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/28 15:59:13 (permalink)
    0
    This was the original response I got:
    "I personally would not recommend the EZBL approach as I feel that it is kind of clunky (large) and the bootloader is actually always running… it never actually gives full control to the application. "
     
    I am not worried about size as I am only using 14% of my flash.  On the case of "bootloader always running", I guess using the EZBL it is always running in the background and can allow sending a bl2 file at anytime.  The classic way I think of the bootloader is it would run once after a POR, and then jump to application code where it would stay until next reset.  But, I am not sure if there would be any issues if the EZBL is running "in the background".  He sent some snippets of code from EZBL and I guess there are ways to disable having the EZBL running in the background.  I am just starting to work on the bootloader and will check out the EZBL code soon.
     
    Also, the XCP went pretty smooth.  We were able to get polling and DAQ working well with CANape, but we are not monitoring/calibrating that many parameters. 
    #17
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/28 19:59:08 (permalink)
    0
    I think what I am going to try first is creating a bootloader for my MCLV2 board first, since it has UART and that is already "built in" and once I understand everything and if all goes well, I will do a conversion to CAN for the actual board.  Working on the bootloader, there isn't any chance I can mess up the device where it is unable to accept new firmware or run code, is there?  Because the way I see it, if something goes very wrong with the bootloader code, I can just take control of microcontroller with the debugger/PICkit3 and flash/run like like I have been doing, or try to fix the bootloader and reflash it with the PICkit3. 
    post edited by ASICAlex - 2019/03/28 20:03:10
    #18
    ASICAlex
    Starting Member
    • Total Posts : 43
    • Reward points : 0
    • Joined: 2018/02/27 15:40:02
    • Location: 0
    • Status: offline
    Re: CAN Bootloader 2019/03/30 20:44:15 (permalink)
    0
    I have been playing with the EZBL and I think I understand what the Microchip engineer was talking about.  The bootloader is kind of like another separate app that is always running, but looks like I can just forward any shared interrupts between the two so when it hits the bootloader code during normal operation, it will just jump back to the application.  I have been messing with my mclv2 eval board and messing with the EZBL over the UART interface and have been able to successfully program the ex_boot_uart bootloader to it, and then able to update the firmware with my normal code I am running on the eval board over UART.  I just had to add the appropriate files to my project. I am trying this first just to see if I can understand everything that is going on, which I am still far from.
     
    Now I guess is the tough part, and will have to add CAN capability to the EZBL.  I guess I need to now add CAN functionality to the ezbl_lib library, and then build that.  Then create a new project, perhaps called ex_boot_CAN, that includes this new library and then flash the ex_boot_CAN to the device?  Basically instead of the bootloader grabbing data from a UART FIFO, I need it to grab the data from the CAN buffer in memory, so I need to understand how that "pipe" works better. 
    #19
    Stampede
    Super Member
    • Total Posts : 400
    • Reward points : 0
    • Joined: 2006/10/04 05:59:28
    • Location: Germany
    • Status: offline
    Re: CAN Bootloader 2019/03/31 10:09:35 (permalink)
    0
    ASICAlex
    This was the original response I got:
    "I personally would not recommend the EZBL approach as I feel that it is kind of clunky (large) and the bootloader is actually always running… it never actually gives full control to the application. "
     
    I am not worried about size as I am only using 14% of my flash.  On the case of "bootloader always running", I guess using the EZBL it is always running in the background and can allow sending a bl2 file at anytime.  The classic way I think of the bootloader is it would run once after a POR, and then jump to application code where it would stay until next reset.  But, I am not sure if there would be any issues if the EZBL is running "in the background".  He sent some snippets of code from EZBL and I guess there are ways to disable having the EZBL running in the background.  I am just starting to work on the bootloader and will check out the EZBL code soon.



    Running in background can be turned off by forwarding interrupts. Yes, it uses a good amount of flash, but so what...?
    ASICAlex
    I think what I am going to try first is creating a bootloader for my MCLV2 board first, since it has UART and that is already "built in" and once I understand everything and if all goes well, I will do a conversion to CAN for the actual board.  Working on the bootloader, there isn't any chance I can mess up the device where it is unable to accept new firmware or run code, is there?  Because the way I see it, if something goes very wrong with the bootloader code, I can just take control of microcontroller with the debugger/PICkit3 and flash/run like like I have been doing, or try to fix the bootloader and reflash it with the PICkit3.

    You can mess it up. If the bootloader "is not running in background", your application need to make sure you can safely reset the device and get in the bootload state. If that fails, you have this BOOTLOAD_TIME time out. The ezbl will wait for 2 or 3 seconds by default until it trys to start the application, here you can now start bootloading. Unless you force this timeout to 0, is very difficult to brick the bootloader.
     
    ASICAlex
     I guess I need to now add CAN functionality to the ezbl_lib library, and then build that.  Then create a new project, perhaps called ex_boot_CAN, that includes this new library and then flash the ex_boot_CAN to the device?  Basically instead of the bootloader grabbing data from a UART FIFO, I need it to grab the data from the CAN buffer in memory, so I need to understand how that "pipe" works better.

    No, the ezbl library (ezbl.a) can stay the same. However, you should create a new project (e.g. ex_boot_CAN), add the library and write your own CAN drivers within this project. You just need to call some of the EZBL_FIFO functions and their respective callbacks to interact with the bootloader. This way, its much easier to integrate future releases of the ezbl into your project.


    CHeers
    Stefan
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5