DFU-UTIL under Windows 7 with Maple as FLASH

LeafLabs Garden » Support » Maple IDE Support

DFU-UTIL under Windows 7 with Maple as FLASH

(20 posts) (4 voices)

Started 5 years ago by x893
Latest reply from poslathian

12 Next »

x893
Member

Hi
i use maple-ide under Windows 7. If i use RAM to upload - all work fine. After select Maple as FLASH configuration and upload Blink sample to board i see that flash contains not equal to file Blink.cpp.bin
Normal flash content must start from 8005000 and above. But if i upload with dfu-util contain wrong
8005000 - 80053FF = 0xFF
8005400 - 80057FF = correct content of Blink..bin 400-7FF
8005800 - 8005BFF = 0xFF
8005C00 - 8005FFF = correct content of Blink..bin C00-FFF
etc.
as i understand problem not deal with maple-ide but may be you suggest any way to resolve issue under Windows 7

Thanks in advance

Posted 5 years ago #
bnewbold
Ex-Leaflabs

Hi x893!

For clarity, regardless of the memory structure, does the program fail to run correctly when compiled and uploaded to FLASH through the IDE? Or are you just curious? I can't think of any reason that Maple programs would get compiled and uploaded to different memory locations from Windows 7 vs. any other platform.

What tool are you using to do disassembly? I'm not the local linker expert, but it's possible that the 0xFF padded sections of FLASH are intentional... if you read the bootloader code it looks like it grabs the actual reset jump vector from an 0x04 offset and actually starts from a different address:
http://github.com/leaflabs/maple-bootloader/blob/master/hardware.c#L157

PS, this bootloader code is EMBARRASSING!

Posted 5 years ago #
poslathian
LeafLabs

I dont know the exact locations off the top of my head (in fact, its mostly up to the compiler, although youd expect somewhat predictable/deterministic results in general). The only constraint we put is that the vector table starts at 0x80005000. The jump address for the startup code should be stored at 0x80005004, but even that code is not yet "blinky" The startup code will copy initialized variables from .data into RAM and will initialize uninitialized variables from the .bss section into ram by setting them to zero. I believe that for c++ support, the startup code will also run the constructors for various global objects etc.

Point being, It should be expected the the actual "blinky" code does not end up in 0x80005000. While removing the bootloader and uploading via JTAG should get the vector table into 0x80000000 and save you 20k of program ROM, you should still expect blinky to be further down in memory because of the vector table and the startup code.

Posted 5 years ago #
x893
Member

Hi bnewbold,
i use maple-ide to compile and prepare bin file. after dfu-util complete upload i use system boot mode and "STMicroelectronics flash loader.exe" to read flash and compare with uploaded bin (via dfu-util). and see what one 400h block normal and other not programmed. if i use "STMicroelectronics flash loader.exe" to upload the same bin to flash - all work fine (bottloader start, blinks led and start my program). Of course i can use system boot to upload but want to use maple ide (or use visual studio and dfu-util as bootloader). i can suggest what problem deals with dfu-util originally write for linux/mac and has a problem in windows 7 (as i understand under xp it works).

Posted 5 years ago #
poslathian
LeafLabs

I am not sure I totally understand your problem. You create binaries with maple-ide, and then if you upload via dfu-util it stuffs a corrupted binary into flash? If you upload via some other loader (over serial?) using st flash loader you successfully upload a non corrupted binary?

I should mention that if you use the leaflabs toolchain straight through (maple ide and dfu-util programming via leaflabs bootloader) then the following should be true:

program binary should start at address 0x80005000, that binary will be loaded by the bootloader into address 0x80005000. However, the actual program flash memory starts at 0x8000000, so if you read back out the current flash contents and compared it with the binary you were loading they should not be the same. That is because the first 20k of memory in flash (0x80000000-0x80004FFF) should contain the bootloader itself and not the binary you just created.

Could you give some more details?

Posted 5 years ago #
x893
Member

Hi poslathian,

first question - answer yes

i program first 20K (from 8000000) via serial line (system bootloader) and STMicroelectronics flash loader.exe. It's equal maple-bootloader and work fine.

After i use maple-ide to compile/upload code (simple blinky sketch) to board.
It's say all ok but not work. I switch system bootloader again and read flash (from 800000 or from 8005000) and compare - from 8000000 to 8004FFFF with maple-bootloader and 80050000-.... with blink bin file (from TEMP/..... folder).

I can find sources of dfu-util only from Openmoko but it's not equal to maple dfu-util.
Where i can find sources for your version of dfu-util ?

Also i start to adopt project Device_Firmware_Upgrade from ST (um0424.zip) to compare with dfu-util (for maple pins).

Thanks
Mitek

Posted 5 years ago #
poslathian
LeafLabs

Ill have to hunt around for the source of our version of dfu-util, i think it was a snapshot of the repo from a while ago, it was stable to we held on to it. I believe dfu-util is back under active maintenance.

The ST DFU upload will not work with the maple bootloader. In fact, the ST DFU is not DFU at all, but "DFUse" where the "se" stands for "st extended." This program is designed to work only with the ST DFU firmware (feel free to give this a try!) and it is not in anyway DFU compliant. the DFUse firmware wraps a propietary non-dfu protocol around a set of DFU device enumeration descriptors, and most of the heavy lifting (flash page clear/write algorithm) is left up to the host PC "DFU firmware uploader" software. Do let us know if you are able to use that software though.

Can you share some of these binaries with us? We officially dont support win7 yet, but were getting there, and have are building a win7 test box. We have had several successful reports of users working with win7, but were still building up the list of "caveates" for us to fix for an official win7 release. Thanks for your help pointing out these problems!

Posted 5 years ago #
x893
Member

I make next actions for test
1. Adopt Device_Firmware_Upgrade from ST for Maple platform with led blinks, delay and USB pin analyzing/disconnect.
2. Convert Blink.cpp.bin to dfu format and upload it to Maple via DfuSeDemo.exe
Perfect result under Windows 7. All write correctly.
3. Make a simplest dfu-util (on C#) which convert .....cpp.bin (from maple-ide) to ST dfu file and upload it via ST dfu protocol.

Now not a problem with Windows 7
Thanks for all

Posted 5 years ago #
poslathian
LeafLabs

interesting. so youre using the ST DFUse firmware as a bootloader running on maple? You are NOT using the maple bootloader....if you are than I will be very surprised!

Posted 5 years ago #
x893
Member

Yes - i not use maple bootloader currently. Also i remove SPI and NOR download and add RAM download. I see dfu-util source - it's very easy. May be problem in libusb on W7. Can't say exactly - need time for investigation.

Posted 5 years ago #
x893
Member

Can you place your bootloader as binary file ?

Posted 5 years ago #
bnewbold
Ex-Leaflabs

Our "factory" versions of the bootloader are available as .bin files at http://static.leaflabs.com/pub/leaflabs/maple-bootloader/

The rev3 version we currently ship with is maple_boot-rev3-9c5f8e.bin

Posted 5 years ago #
manelcig
Member

Hi,

I'm facing exactly the same problem. I'm working with another board with an STM32F103RET.

I tried using your bootloader, remade the makefile to work on windows and flashed it with jtag.
Using the maple-ide I can upload the blinky example and all seems to go fine.
However dumping the mem contents with OpenOCD it appears that instead of the code going to right places it goes to the locations referred on this thread's first post.
I can only see 2 possibilities. Changes made to the makefile broke something, or linker file problem due to it being a high density device.

Posted 5 years ago #
poslathian
LeafLabs

I wouldnt expect things to work stock with a higher density chip. You will definitely need to adjust the linker files in github-repo/libmaple/support/ld

Posted 5 years ago #
x893
Member

Hi again,
after some investigation i understand problem.
Low density STM32 has 0x400 page size (1024 byte) but medium (for ex. RET6) has 2048 bytes page size. You use 1024 packet size and erase page on each packet (by write address). After transmit first block (at address 8005000) use corrently erase page and flash 1024 bytes. After trasmit second block you erase page (but for 2048 block you erase first block also) and write second block correctly (but first block erased). It means that each even block erased and odd block correct.

I try use -t 2048 parameter in dfu-util but bootloader crash with this block size.
Because your bootloader code very professional i can't suggest way to resolve this issue.

Best regards
Mitek

Posted 5 years ago #

RSS feed for this topic

12 Next »

Reply »

You must log in to post.