A few days ago i also contacted my supplier and he tried to help.
All i got until now: 2 hex-files and the advice to put the file(s) on a fat formatted micro sd-card in the root directory. I tried this, but using the installed bootloader firmware i think it is not possible to update the device by using an sd-card. The file has to be copied on the virtual disk drive and installed from there as .rdy file.
I think the hex file has to be different. Instead of an app and a sys- file we need the files similar to the DSO-Quad files.
I have just received two hex files from my seller App v2.60 (as already installed) and Lib v2.25 (my nano was delivered with Lib v2.26 installed).
I copied these into the nano (just as you do with the quad) and rebooted, sure enough it now has App 2.60 and Lib 2.25 installed. With great excitement I then copied Benf’s files into the nano and rebooted to only find it still had v2.60 and Lib v2.25, so the only change has been to go from Lib 2.26 to Lib 2.25
It does however indicate that the method of upgrading works just as the quad and that maybe benf App 3.64 is not compatible with this method of installation. Could benf cast any light on this?
Just a thought, I am trying to load Benf App 3.64 with Benf Lib 3.53 as downloaded from the forum. Is this the correct Lib file to go with the App 3.64 ?
As always any help much appreciated.
If you are allowed to redistribute those files, I am sure some curious ones would take a look if you attached them here…
But from where did your vendor get these files? He should escalate this issue further upstream. It should not be Benf or people on Seeed forum who should need to sort this out, although many here are happy to help.
Does anyone have a connection at eDesign? Maybe they know something about this new bootloader? At least it seems they wrote it. The question is if they approved its use on the DSO Nano? Anyway someone made these hex files and they must know.
My nano was delivered from UK although the e-bay listing quoted source as China.
The files were delivered as attachments to an e-mail from someone called guojun Ding from goodness knows where ??
Interestingly the Benf files appear to be accepted by the nano as they show as RDY after copying them into it (just like the quad) but on reboot it still has the previous app running.
I tried messing about with file names and upper and lower case as the files from guojun Ding were in capitals and were just LIB_V225.HEX and APP_V260.HEX I changed the benf files to this type of filename and they then wouldn’t load, just came up with ERR instead of RDY. Don’t know if this casts any light on the problem or just adds confusion.
I’ve been asked to share my experience with bootloader flashing. Please excuse me if anything is wrong - I’ve got a really short memory. But just in case I tried to reflash the bootloader once again and it seems to be working. So here’s the instruction:
STM32F103VBT6 has different boot options, selected by pins BOOT0 and BOOT1:
Table 9. Boot modes
Boot mode selection pins Boot mode
Aliasing
BOOT1 BOOT0
x 0 Main Flash memory Main Flash memory is selected as boot space
0 1 System memory System memory is selected as boot space
1 1 Embedded SRAM Embedded SRAM is selected as boot space
If you look at the schematics you’ll see that BOOT1 (also PB2) is hardware-tied to ground, so only two first options are available. There’s BT0 pin broken out on the CN4 pin header. If you leave it floating (pulled down) it will jump to address 0x8000000, if you pull it to VDD, it will jump to built-in bootloader, available on USART1 (more on bootloader in section 3.4 of reference manual). The firmware itself consist of (another!) bootloader and application. The DSO (not MCU!) bootloader sits in the memory starting from address 0x8000000. The application sits in the memory starting from address ().
When you plug in the power, MCU first checks the BOOT pins and if BOOT0 is pulled up it takes you to the MCU bootloader (more on that later). Otherwise it runs to DSO bootloader that in its turn checks if DOWN key is pressed. If no -> jump to application. If yes -> go to DFU mode.
Now, we want to replace DSO bootloader. To do so, we simply need to pull BOOT0 pin up (short with a piece of wire BT0 and 3V on CN4) and feed the DSO bootloader to the MCU bootloader that is patiently waiting for bytes to come in through USART1 (also broken out in the PCB).
Now, to the step-by-step.
Connect BT0 (at CN4) to 3V (e.g. at CN4)
Connect USB-UART (TTL at 3,3V, pins GND, TX, RX) to CN5. I did not connect VDD and used 5 volts converter, but you’d better check in the datasheet that both pins are 5 volts tolerant (marked as FT)
(May be the hardest part) Download the Flash Loader Demonstrator from the ST website and install it on a PC running Windows
Start the Flash Loader Demonstrator and in the first screen select the COM port connected to the board under Port Name. Ensure that the baud rate is also set at 115200, with Even parity, Echo disabled and Flow control off. Press Next. If you are succesfully connected to the board, you should see the message “Target is readable” and “Flash Size 128 KB”. Please click “Next” to proceed . Press Next and you will be prompted to select a target. Select STM32_Med-density_128K, then Next to go to the Operation choice page.
By now you should have downloaded the bootloader *.bin file and know it’s location. Select “Download to device”, browse for dsonano2-loader.bin, and choose “Global Erase” option. “@ (h)” field should automatically set to 8000000. If all is OK, hit Next and you should witness the bootloader being flashed to the MSU.
If all is done OK, you’ll see the message “Download operation finished successfully” on a green line
Now plug off the power, take all the wires off the DSO and plug it back. You’ll see “Firmware upgrading” message on the DSO screen. The device is in DFU mode. Now just follow the regular application update procedure.
Btw, you can also flash application and hw files the same way - just check that they go to the right address and you don’t choose “Global Erase” each time.
Many thanks to andrey for a detailed instruction list. I am only a humble hardware engineer so a lot of the software talked about on this forum is beyond me!
My opinion is that having bought a brand new piece of kit (no matter whether it costs £50 or £500) is that it ought to do as the manual suggests and I should not have to spend time opening it up (invalidating warranty, possibility of messing up the operating system etc) to make it do what the manual says it should do as supplied.
I enjoy playing with kit as much as anyoine but this is getting beyond my idea of fun.
Any other opinions?
I have just received this advice from my supplier:-
hi:
The newly DSO will only compatible *.hex format firmware . If you want use Benf’s firmware ,please change the *.dfu file into *.hex with programming software .
malsdewd
All I have done is to merely change the file extension of benf files from .dfu to .hex then copied them into the nano (just as I do with the quad) and all seems fine giving the RDY for both files in the nano but as we know on reboot the nano returns to the existing App.
Does this information from the supplier indicate that the file should be changed to .hex using a particular conversion program? if so does anyone know of this program?
My supplier has responded to my enquiry about whether to just changing the file extension or if a particular program is needed with this reply:-
deaR:
Not change the file extension in windows ,indeed we should rebuild the firmware by our own-self . Because the Benf’s firmware is written by the third author . thank you!
malsdewd
Don’t really know if this helps. Is BenF out there, please can you advise the way forward, I really would like benf 3.64as the 2.60 installed as supplied is very poor.
Having pursued this further with my supplier I have received this (apparently final) reply:-
deaR:
i am sorry, you can not put the third party firmware into our NANO, just can use our firmware, thank yu for our understanding!
have a nice day!
malsdewd
As you can imagine I am not a happy soul as the V2.60 is next to useless, I am going to try to get a refund as it is not as described, see how far I get!!
First of all, Andrey, thank you very much for coming here and writing up the HOWTO. Thank you for putting your Nano through the bootloader flashing abuse once again for us to confirm the steps. I am truely greatful. Спасибо Вам большое.
If I understand correctly, you have to get USB-UART hardware like this ebay.com/itm/Serial-Converte … 4151d82e65 ? FYI, I have not used theses boards or sellers. Its was a quick search.
I highly doubt we can flash old Nano bootloader using e-Design bootloader to flash over itself.
So possibly the easiest way would be to make proper .hex files of Benf firmware.
Can someone attach the 2.60 firmware hex? I want to compare hex formats to Benf.
update: Looked at Quad .hex and Benf .hex and they are different. So we need to rearrange stuff like Recompute offset, split data into 16 bytes per line and compute new 8bit checksum at the end.
Hi motopasscode, I have tried your benf files with no success. The hex files go through all the usual pattern and show as RDY files after copying into nano but it reverts to V2.60 after reboot, the bin files produce a NOT message on both files after copying.
I will try to attach a copy of the 2.60 APP and 2.25 LIB as installed on my nano but if not someone provided a link to it a page or so earlier in the same thread.
Many thanks for any help you can offer. My supplier has told me to return my nano to China (not a financial option on a £40 item) and he will then decide whether to send me another or refund so I am stuck with it. The 2.60 is terrible but Benf 3.64 looks very good to me and this is why I bought a nano. App 2.60.zip (42.1 KB)
Hi, firstly many thanks for your help with this issue.
I have downloaded your latest Benf 3 app and copied this and your hex version of LIB 3.53, posted earlier, but sadly the outcome was just as before, both appear as RDY but the nano still reboots into the existing V2.60
Sorry I can’t offer any constructive input but software isn’t my department, I would just like the nano to be as good (as far as the spec allows) as my quad is since installing 2.53 and Benf 3.64 looks very good
Thanks again
For flashing a bootloader yes, you need a UART (there may be options like RS232<->UART converter) and the easiest way is tu buy a USB<->TTL adapter. Cheap like hell. Can do your own as well (e.g. roboforum.ru/forum4/topic10592-15.html#p232256 - sorry, it’s in Russian). If you use a scope you need other convenient tools, so it’s a good investment. You can also consider more complicated tools like BusPirate. Does an awful lot of things but it will take time to learn how to handle it.
Also, there was a piece of software that did *.hex to *.bin convertation. Will try to find it for you - can’t remember what’s the name of it…
Right, search for “usb ttl” on eBay and you can find them for less than 3 $ (with Free Shipping/Buy Now), including cables. Seeed only sells more specialized usb to serial boards as far as I can see.
On Linux you can use:
objcopy -I ihex -O binary file.hex file.bin
Anyway, I guess the problem is not the differently formatted hex files, but that eDesign(?) has added some checksum or “certificate” to make sure only their firmwares can be installed. Effectively shooting themselves in the foot, since their firmware is a joke compared to the independent third-party firmware from Benf.
I just flashed the BenF software on the DSO201 with the the new bootloader.
I took the hex files generated by the IAR Compiler and also changed the file names. (V201_LIB.HEX, V201_APP.HEX) and now it works. DSO201Flash.zip (34.2 KB)
Alf, that has fixed it for me as well. Haven’t checked it all but looks good so far.
Many many thanks to you and everyone who has devoted time to solve this problem.
I won’t be sending my nano back now, now going to learn the ins and outs of benf’s app.
Just a quick question, it comes up as app ver 3.11 how does this differ from the 3.64 app?
Thanks again
Having pursued this further with my supplier I have received this (apparently final) reply:-