Adapting iNEMO v2 virtual com port, DFU code for Olimex STM32 board

[harinath]

Posted on May 03, 2012 at 11:58

Hello everyone,

I have Olimex STM32-P103 bord which has STM32F103RBT6 micro. I

flashed Virtual com port DEMO .hex file from the example code they provided. With some technical support from Olimex, Windows 7 virtual com port driver is working. But the example uses very old version( v1.0) libraries. I want to use FreeRTOS for implementing my application. I also need DFU support.

I also have STEVAL-MKI062V2

http://www.st.com/internet/evalboard/product/250jsp

with micro STM32F103RET7. ST provided Firmware project source for IAR Embedded workbench.

It has virtual com port code with DFUsupport. I want to utilize this code to make STM32-P103 board communicate via virtual COM port with DFU support.I'm working with

IAR EW+

FreeRTOS+

ST-LINK+

WINDOWS 7.

I created project, configured & programmed the Olimex board. But the board is not recognized on COM port.

When i DEBUG & see, the debugger stuck in the while loop shown in the code. which means something is wrong in USB related things( i guess clock configuration & driver related).

 void

inInitTask(

void

*pvParameters)

{

iNEMO_HW_Config();

//Configure the hardware for the iNEMO platform

while

(bDeviceState != CONFIGURED);

// THIS LOOP IS GOING INFINITE

iNEMO_Config();

// Initialize the iNEMO sensor platform

Timer_Config();

// Configures the timer 2 for frequency interrupts in Hz

}

In adapting the iNEMO v2 code for Olimex board, i did the following.

1. Created a project & configured it to suit medium density devices in Linker option config file. Also modified Startup_stm32f10xmd.s file to suit in FreeRTOS environment as below:

EXTERN __iar_program_start

EXTERN SystemInit

EXTERN vPortSVCHandler ; defined for FreeRTOS

EXTERN xPortPendSVHandler ; defined for FreeRTOS

EXTERN xPortSysTickHandler ; defined for FreeRTOS

PUBLIC __vector_table 2. Configured DISC,

push button & status LED

pin of Olimex board to suit iNEMO board DISCONNECT pin of USB & push button, status LED buttons. Rest of the code of iNEMO is commented out.

3. I did not change descriptors related to USB.

I don't know where I'm wrong. I'm quite sure that my problem related

clock configuration &

driver. How to use the

driver inemo folderso that Olimex board can be recognized by computer.

I

attached working version

main.c file from virtual com port example from Olimex. It uses old libraries. Is the

clock configuration in this file is same as

iNEMO v2 board ?

I described this problem more clearly here:

http://harinadha.wordpress.com/2012/05/03/olimex-stm32-p103/

#dfu #usb #virtual-com-port

[BenMack99]

Posted on May 17, 2012 at 11:01

Hi Harinath

I don't have any answers for you, but I'm also looking at implementing DFU on a STM32F103RB, using a bootloader similar to that used in the iNemo. My intention is to allow field engineers to update firmware via USB rather than JTAG, and also configure the target by loading a config image directly into a designated config block in flash, again via USB.

I've downloaded the ''iNEMO GUI and firmware'' from http://www.st.com/internet/evalboard/product/250367.jsp, and am going through the firmware supplied with it, and trying to make sense of it. I assume this is the main bootloader module

<install path>\Firmware\iNEMO_DFU_Project\iNEMO_DFU\Application\src\main.c

which inits the USB, then goes into a loop while(1){}. However I don't yet understand how data is transferred between USB and flash - I guess I need to concentrate on

<install path>\Firmware\iNEMO_DFU_Project\iNEMO_DFU\Device_Firmware_Upgrade\src\iNEMO_dfu_mal.c

I have some questions:-

- is this roughly what you are doing as well?

- does this seem a sensible way to get DFU working in the STM32F103RB, or is there a ready-made DFU bootloader binary I can use?

- are you trying to build a single binary that includes this DFU stuff plus your main app running under FreeRTOS? I'm hoping to build a simple standalone bootloader binary that is loaded into flash via JTAG at 0x08000000, and then load whatever user code I want at 0x8003000

Any advice gratefully received, I'm a bit new to all this

Cheers

--

Ben Mack

Designerds - electronic design consultants

http://designerds.co.uk

[harinath]

Posted on May 18, 2012 at 05:39

Hi Mack,

I'm happy to see your reply( at least i found someone who is working on the same). My approach is same as iNEMO firmware. It has two .hex files, one for DFU and the other for application. DFU .hex is dumped at 0x08000000, application .hex dumped from 0x08003000.

You may consider DFU .hex as DFU bootloader.

Still I have the problem described above. I have clock config, startup file modification. But at present i took a little different path though i need the original way of iNEMO firmware. Now my main aim is to test my sensors connected to the board, so not working on this problem.

DFU Hardware mode:

If you have a look at DFU firmware source, its very clear. if the user button is pressed before starting the iNEMO board, it will enter into DFU mode, allow the user to upload DFU image of application. If not pressed user button, it will jump to application code.

DFU Software mode:

This is when device is running application code. If user sends, enter DFU software command, FLASH will be unlocked, then DFU application in PC takes control & starts dumping code into the FLASH from 0x08003000. Upon completion, device will be software RESET. Then iNEMO board will start running application code.

I'm facing problems in coding using the FreeRTOS environment. For any updates on this problem visit my blog. I will write complete solution once i solve. If you solve, please leave a message for me.

Note: You need to make .dfu images to use DfuSe GUI to upgrade firmware. Use DfuSe manager to create .dfu images from .hex files.

ST seems sleeping here, not answering any of the threads.

Thank you

[BenMack99]

Posted on May 23, 2012 at 08:37

Hi Harinath

BTW my first name is Ben, Ben Mack, I don't know why this site calls me Mack Ben ;)

(Aha, PS just fixed that)

I've also been diverted away from working on this problem for now, but still interested in your thoughts

So is your problem just with entering DFU mode in your application code (using FreeRTOS)? I won't be trying that, my app can trigger a reboot to run the DFU bootloader code at 0x08000000

The bit I'm unclear about is how the bootloader DFU code works. I can see how it initialises the USB and unlocks the Flash, but how does the data get transferred? In the connectivity line devices the DFU handlers are in the system firmware, but in the 103RB we have to code it ourselves.

Thanks for the tip on creating .dfu images

Cheers, Ben

[harinath]

Posted on July 23, 2012 at 12:31

Hello all,

I succeded in making virtual COM port driver in FreeRTOS environment. If anyone interested visit 

http://www.harinadha.wordpress.com/

.

Thank you