Issue on use DFU on STM32L Discovery

[henryns2009]

Posted on October 25, 2013 at 18:34

Hi, I am working on the DFU recently.

1. I modified a STM32L Discovery board with STM32L152RBT6 to have USB capaility. http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF250990

2. Then I loaded the ''Device_Firmware_Upgrade'' project into my Discovery board and the PC found it as a DFU device. 

3.I used the ''binary template'' project in the STM32_USB-FS-Device_Lib_V4.0.0 to generate binary file. This project just simply uses the system tick for timing and toggles the use LEDs every 300ms. 

4. Use DFU File Manager to convert the binary file to a DFU image.

5. The DFU image is loaded by DfuSe and everything worked nicely.

However, when I do the same things to a more complicated project, like the ''Virtual_COM_Port'' project also in the STM32_USB-FS-Device_Lib_V4.0.0, it failed to work.

BTW, I made the ''Virtual_COM_Port'' project work on my STM32L Discovery before changing the address from 0x08000000 to 0x08003000.

Have anyone have the same issue? 

Thanks

[Tesla DeLorean]

Posted on October 25, 2013 at 18:56

Have anyone have the same issue?

You've modified an STM32L-Discovery to do USB, I suspect your audience here is going to be very small.

So is the question have people run in to DFU problems? What exactly are you reporting as a problem? What failed to work? Does the DFU update not work, is the VCP crashing, or not functioning correctly in some way related to DFU? What kind of debugging have you done?

[henryns2009]

Posted on October 25, 2013 at 19:54

Thank you for your quick response. I thing engineers using DFU with STM32L15xx MCUs can help too.

The DFU software worked well. I believe they did what they should do.

It is just the VCP does not work at all. The PC cannot recognize the VCP any more. 

What I notice that content of the binary files with address 0x08003000 and 0x08000000 are different. Will that be the reason why it did not work?

Below are the binary files opened with STM32 ST-LINK Utility. They are compiled with IAR Workbench. You can see there are many difference even they both let the LED toggled the same way.

   

[henryns2009]

Posted on October 25, 2013 at 20:13

One more interesting thing I noticed that. 

In ST's user manual(UM0424 pp79) of making a binary file for DFU, we just need to changed some settings in the compiler from 0x08000000 to 0x08003000.

However, there are many registers using address 0x08000000 as base address in the *.h files.

I am wondering if the setting changing is sufficient?

[Tesla DeLorean]

Posted on October 25, 2013 at 21:20

SysTick_00 is not built for 0x08003000 operation, note the addresses in the vector table.

It is critical that the linker build the image for 0x08003000 (or whatever the basis needs to be). Your second example appears to meet that criterion.

Can you be more specific about the .H files with absolute addresses? It is the linker, via linker scripts, or scatter files, that determines where the code gets situated.

[henryns2009]

Posted on October 25, 2013 at 22:03

I can tell the address are different from the vector table. But interestingly, they both worked if I debug them directly with IAR Workbench.

Check ''stm32l1xx.h''. There is

''#define FLASH_BASE            ((uint32_t)0x08000000) /*!< FLASH base address in the alias region */ ''.

I played with this file a bit. It did not help at all.

[henryns2009]

Posted on October 25, 2013 at 22:11

Again, in ''misc.h'', there is

#define NVIC_VectTab_FLASH           ((uint32_t)0x08000000)

[Tesla DeLorean]

Posted on October 25, 2013 at 22:26

Ok, and that is likely used in SystemInit() from system_stm32l1xx.c (or equivalent), and used to set the Vector Table (SCB->VTOR) with the correct value. You have to focus on where they might be used.

The system_stm32l1xx.c should be localized within your project, and modified to relate to your system, clocks speeds, and code placement requirements.

I don't particularly care for ST's solution for programming the vector table address, I made the assembler externalize the vector table address, and had the linker generate the value automatically.

[Tesla DeLorean]

Posted on October 25, 2013 at 22:31

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Bootloader%20Problem&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=3825]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FBootloader%20Problem&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=3825

[henryns2009]

Posted on October 25, 2013 at 22:34

Thank you for your help.

I finally make it work by changing the 0x08000000 to 0x08003000 in the all relative head files.

There is a need to update UM0424.

Nice.