Problem with DFU

[mika]

Posted on June 09, 2009 at 08:19

Problem with DFU

[mika]

Posted on May 17, 2011 at 12:46

In short, the problem is that the board doesn’t go into DFU mode (anymore).

I have STM3210E-EVAL board. I reset the board by pressing the Key-button so that it went to DFU mode and I was able to use DfuSe Demo (v2.2) and DFU Tester (2.1). That is, I managed to install STDFU driver in PC and saw the device in the tools. With DfuSe Demo I managed to download the demo firmware (ready made image, v1.1.1) in the internal flash. I also tried to download the USB development kit demo images (um0420.zip) in the device and they seemed to work fine. Then I built the JoyStick demo, of which sources and project are included in the um0420.zip, with Ride7+ARM kit+GNU and converted the hex binary to a dfu-file by using the DFU File manager. The joystick demo didn’t work because verifying the download with DfuDemo fails. This is another problem – later on this… However, then I tried to download the self build joystick hex binary with DFU Tester. The joystick demo didn’t work. Then I tried to get the device in DFU mode again. The device doesn’t go in DFU mode when Key-button is pressed. When JP14 is in 2-3 position, PC doesn’t react in any way when plugging the usb. When JP14 is in 1-2-position, the PC notices the device but doesn’t recognize it. So, is it possible that the DFU firmaware in device has somehow corrupted? Can USB development kit demos affect somehow? Or am I missing some simple thing here? The original problem, that I was trying to solve before ending up in this situation, was that self build images failed to work, because the verify in Dfu Demo failed. With Dfu Tester, I noticed that code start address in the ready given DFU images is 0x08003000 while in self made images it is 0x08000000. Also I noticed, with Dfu Tester, that the pages from 0x08000000 to 0x08003000 are read only? I changed STM32F103_512K_64K_DEF.ld file in (C:\Program Files\Raisonance\Ride\Lib\ARM) by editing the line FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 512K by changing the address to 08003000. (Also made so that the file is not overriden when regenerated by Ride during build.) Images build in this way didn’t work either. I don’t have RLink or similar, yet. How to get the deveice in DFU mode again? How to make those example Ride projects to work?

[16-32micros]

Posted on May 17, 2011 at 12:46

Hi mika,

I think that you have erased your DFU code when you have used the DFU tester and so the DFU Code in the first pages of the flash is not able to enumerate again USB. The only way to make it running, is to put a new DFU demo in your first pages : This can be either done via JTAG tools like Rlink or also you can use a simple RS232 connection with USART1 using the internal boot-loader of STM32 : http://www.st.com/stonline/products/support/micro/files/um0462.zip and document here

http://www.st.com/stonline/products/literature/um/13916.pdf

. Let me know if you need some others hints. Cheers, STOne-32.

[lanchon]

Posted on May 17, 2011 at 12:46

hi mika,

please confirm that you erased the DFU code via USB and not through JTAG or the serial bootloader. you shouldn't be able to do that unless there's a bug in the DFU code. or should you?

[mika]

Posted on May 17, 2011 at 12:46

Thanks for the answer. I see now that this was exactly the problem.. :D

Kind regards, Mika

[lanchon]

Posted on May 17, 2011 at 12:46

oh that's ugly, I hate bootloaders that can commit suicide. that may or may not be ''intended behavior''. if you still have the source code and binary that caused the event, maybe you'd like to file a bug report via support. in any case, thanks for the clarification.

[mika]

Posted on May 17, 2011 at 12:46

Oh.. As I described, I was using DfuSe Demo and DFU Tester tools and USB connection only. I hadn't means to use JTAG or serial connection. Anyway, the board stopped to appear as a ''STM Device in DFU mode'' to host PC after the steps I described in my original post.

regards, mika

[16-32micros]

Posted on May 17, 2011 at 12:46

Hi lanchon,

Did you know or tried to use STDFUTester and what is this GUI for ? Let me know if I have missed something :-Z Cheers, STOne-32.

[lanchon]

Posted on May 17, 2011 at 12:46

no, never. but if the DFU firmware kills itself, it's either the result of intended behavior or a bug. I don't see it as a good thing that a bootloader is able to kill itself, so I thought it more probable that it was a bug (but with reserve, I said

> that may or may not be ''intended behavior''. ). does the DFU have a way to update itself (or replace itself completely) by moving to ram and overwriting from there? BTW, I believe this would be useful only as a factory programming method (and that it'd be an unjustified risk on most other setups). but the DFU doesn't come pre-programmed on the STM32, or have things changed?

[gregory1]

Posted on May 17, 2011 at 12:46

Quote:

On 05-10-2008 at 15:20, Anonymous wrote: Hi mika, I think that you have erased your DFU code when you have used the DFU tester and so the DFU Code in the first pages of the flash is not able to enumerate again USB. The only way to make it running, is to put a new DFU demo in your first pages : This can be either done via JTAG tools like Rlink or also you can use a simple RS232 connection with USART1 using the internal boot-loader of STM32 : http://www.st.com/stonline/products/support/micro/files/um0462.zip and document here

http://www.st.com/stonline/products/literature/um/13916.pdf

. Let me know if you need some others hints. Cheers, STOne-32. Please, hint what file must be loaded in flash (via USART of JTAG) for reanimating dfu mode? Thank you.