STM32L1: IAP via USB

[mk299]

Posted on September 11, 2014 at 23:17

Hello,

i'd like to extend my STM32L151 device by adding USB bootloading capability. I searched for documentation and examples, but I got the impression that neither of it exists in a complete fashion. To me it seems that there's always some information missing. Mainly I didn't understand which descriptors have to be added or modified. Does someone know a project that consists of a bootloader and an application with all the necessary descriptors and so on? Some helpful source code would also be great. Best regards, Michael #stm32 #usb #iap #stm32l1xx

[chen]

Posted on September 15, 2014 at 16:20

Hi

''i'd like to extend my STM32L151 device by adding USB bootloading capability. I searched for documentation and examples, but I got the impression that neither of it exists in a complete fashion. To me it seems that there's always some information missing. '' Correct. The examples only show simple cases. It is up to you to realise this and have the imagination to know how to add together bits of the example code to achieve what you want. ''Mainly I didn't understand which descriptors have to be added or modified. Does someone know a project that consists of a bootloader and an application with all the necessary descriptors and so on?'' I think you are lacking understanding of USB and the different device types and how to use them. There is the USB DFU device class - Device Firmware Upgrade. ST do provide a full example for this device class. DFU is specifically for doing a Flash upgrade of the code into your device. You can also choose to implement USB CDC - Communications Device Class (RS232 emulation) and implement your own 'bootloader' application code with your own defined RS232 protocol for downloading a binary image. There is not a single example showing you how to do this but there are a few threads where people have discussed this.

[mk299]

Posted on September 16, 2014 at 10:41

Hi,

thank you for your reply. It's absolutely clear that there isn't any example that does exactly what I want, otherwise there would be no need for me to waste my time. So here's some more precise explanation of my questions: I have created a custom HID device and a C# host application, that communicate with each other. Now I'd like to add DFU update capability. In UM0424 two descriptor sets are mentioned: - a ''Run-time descriptor set'' consisting of ''Run-time DFU interface descriptor'' and ''Run-time DFU functional descriptor'' - a ''DFU mode descriptor set'' consisting of ''DFU Mode Device descriptor'', ''DFU Mode Configuration descriptor'', ''DFU Mode Interface descriptor'' and ''DFU Mode Functional descriptor'' My imagination was to modify the DFU loader example to my needs, flash it and load the existing application using this loader (after converting it using the UM0412 tool). But after reading UM0424 I'm confused whether the application also has to be modified to contain information of and/or descriptors for the DFU part. Can I use the application ''as is'' or must I modify it apart from the ''DFU conversion''? Best regards, Michael

[chen]

Posted on September 16, 2014 at 11:08

Hi Michael

''I have created a custom HID device and a C# host application, that communicate with each other. Now I'd like to add DFU update capability.'' ''My imagination was to modify the DFU loader example to my needs, flash it and load the existing application using this loader (after converting it using the UM0412 tool). But after reading UM0424 I'm confused whether the application also has to be modified to contain information of and/or descriptors for the DFU part. Can I use the application ''as is'' or must I modify it apart from the ''DFU conversion''?'' What you are trying to do is harder then just the 'simple example' Firstly you have to understand that you have a single application that enumerates a single USB 'device type' In order to add software upgrade - you need to get the USB to enumerate USB device type - DFU This can be done in a single application with 'USB Composite device' - ie a single USB that has 2 device types with in it. (call this option 1) OR It can be done with 2 separate applications : 1 to do the USB HID and 1 to do the sw upgrade/USB DFU (call this option 2) Pros and Cons of the 2 different approaches: Option 1 : Difficult to load and over write the executing application! USB Composite device - not easy for beginners (FYI - I have not done a composite device myself yet) Simpler to understand memory map/application structure Option 2: 2 separate applications - easier to develop 2 separate applications - each with single USB device type - easier With 2 applications - complexity in controlling which application runs. With 2 applications - complexity in applications memory map (locations) I have certainly done it with option2 many times.

[mk299]

Posted on September 19, 2014 at 20:24

Thank you very much for clarifying this. I'll take option 2, then ;)

Is it necessary that the bootloader resides at the beginning of the flash area? I'd like to execute the application itself after reset/power-up and the bootloader only on demand jumping there from the application when it receives a special command via USB. I'm not familiar with the linker files and startup-code of STM32 - I always used existing ones up to now.

[chen]

Posted on September 22, 2014 at 11:38

''Is it necessary that the bootloader resides at the beginning of the flash area?''

No, it does not need to be done this way but.... what happens if there is a failure during the sw upgrade? The application image may not be valid and therefore the board will be 'bricked'. ''I'd like to execute the application itself after reset/power-up'' The standard trick here is to have the bootloader check that there is a valid application (and that sw upgrade is not requested). If there is one, the bootloader will start the application. All this can happen in us to ms, faster than humans will notice. ''the bootloader only on demand jumping there from the application when it receives a special command via USB.'' As I suggested, make the bootloader run from boot. Then the application needs some way to signal the bootloader to run the sw upgrade. The application need to set this signal (hint SRAM) and then reboot the processor. ''I'm not familiar with the linker files and startup-code of STM32 - I always used existing ones up to now.'' The main file you will need to understand is the linker script - this controls where in physical memory the binary is located. I do not think you have said which compiler/IDE tool you are using. The Linker should have it's own document decribing how to use it. The IDE should have information (documentation) on how to set the linker environment. The only thing that needs to change in the 'standard startup-code of STM32' is the Vector Table location add offset address. I just had a look and it should be in SystemInit() ''  /* Configure the Vector Table location add offset address ------------------*/ #ifdef VECT_TAB_SRAM   SCB->VTOR = SRAM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */ #else   SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */ #endif '' The definition for VECT_TAB_OFFSET needs to set to something other than 0. (Look up the SCB->VTOR in the ARM reference manual because the offset must be on specific memory boundaries but I cannot tell you what they are from memory).