1. Forum
  3. Search

Advanced Search

Search Results (Searched for: bootloader)

  • mwm
  • mwm's Avatar
08 May 2016 21:32
Replied by mwm on topic Ultimate 7e-256k builds

Ultimate 7e-256k builds

Category: Builds

Richard96816 wrote:

HappyHarry wrote: yes these builds will work with the 256k, 384k and 512k replacement mcu's, but as mentioned the ult7e bootloader only currently enables use of ~244k of memory. if the need ever arises that deviation requires more space than the 244k will provide PB said he'll look into hacking the bootloader again to enable this, but I don't ever see this needing to happen.
...

Don't any of the higher capacity, compatible chips have a usable built-in boot-loader?


They all have usable built-in bootloaders. But using them is problematical. Devention (and hence deviation) dfuse tools uses a proprietary protocol. I don't know if the ultimate7e build could work with a standard dfuse tool or still needs one of the Walkera-corrupted ones. So you have issues with needing a dfu bootloader, which the chip may or may not have, and if they do, the hardware connections that it requires, which may or may not be the ones used by the USB port on the transmitter. And of course, they don't know anything about the LCD on the transmitter, so have no way to turn on the display indicating that they are in DFU mode. Using a custom, per-tx bootloader avoids all those issues and makes the install/upgrade process the same on all of them
  • Richard96816
  • Richard96816's Avatar
08 May 2016 21:03
Replied by Richard96816 on topic Ultimate 7e-256k builds

Ultimate 7e-256k builds

Category: Builds

HappyHarry wrote: yes these builds will work with the 256k, 384k and 512k replacement mcu's, but as mentioned the ult7e bootloader only currently enables use of ~244k of memory. if the need ever arises that deviation requires more space than the 244k will provide PB said he'll look into hacking the bootloader again to enable this, but I don't ever see this needing to happen.
...

Don't any of the higher capacity, compatible chips have a usable built-in boot-loader?
  • HappyHarry
  • HappyHarry's Avatar
08 May 2016 18:58
Replied by HappyHarry on topic Ultimate 7e-256k builds

Ultimate 7e-256k builds

Category: Builds

yes these builds will work with the 256k, 384k and 512k replacement mcu's, but as mentioned the ult7e bootloader only currently enables use of ~244k of memory. if the need ever arises that deviation requires more space than the 244k will provide PB said he'll look into hacking the bootloader again to enable this, but I don't ever see this needing to happen.

I will also be adding extra switches and pots when they arrive (waiting on the slow boat) as well as putting the rf modules back in, though I'm still hoping a correctly functioning 3in1 or the devo version 4in1 becomes available soon as I don't like the multi antenna look. I'm going to have to start brushing up on my c++ so as to mod the code for 3 x 3way, 1 x 2way and 2 x pots to work! wish me luck lol
  • silpstream
  • silpstream's Avatar
05 May 2016 04:43
Replied by silpstream on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

I saw that post about 0x08003000 also. It is here , but I never needed to do it.

Could you check your readings again for the resistance values of the 2 resistors next to the BOOT0 jumper pin? They should both be 10K resistors so you should get 10K from the mcu pin to the jumper pin and 10K from the jumper pin to ground.

This next suggestion may sound dumb, but it has happened to me before. Can you look between the pcb and the lcd? I noticed that you soldered the wires in from the top. If the ends are too long, and the angle is just right, you could have the wire touching underneath (out of sight).

I'm running out of ideas without looking at the board physically. I'd be happy to take a look also, but I'm in Singapore (so it could be just as troublesome). PB has already offered and he's definitely more experienced than I am.
  • PhracturedBlue
  • PhracturedBlue's Avatar
05 May 2016 00:45
Replied by PhracturedBlue on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

I've never done so. It can't hurt anything but it shouldn't matter since the bootloader is what causes the jump in the 1st place
  • HappyHarry
  • HappyHarry's Avatar
04 May 2016 23:24
Replied by HappyHarry on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

one last thing, as i was having a bedtime snifter I remembered that i'd read on this forum somewhere that when flashing a bootloader to a bare chip you first flashed it to 0x08000000 then without erasing flash it again at 0x08003000, is this worth trying? or am I remembering wrong? (can't seem to find the post i'm referring to atm)
  • silpstream
  • silpstream's Avatar
04 May 2016 17:56 - 04 May 2016 17:59
Replied by silpstream on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

I'm stumped too. Let's try a few things.

I noticed you have version "V2J24S4". "V2J25S4" is out. So the first thing you should do is update the firmware on your st-link. It is in the menu "ST-LINK->Firmware Update". You'll need to unplug from usb and replug, but do not connect to the processor, just select update right away.

I also noticed that your first picture shows "SWD Frequency = 4,0 MHz", but you settings shows "1,8 MHz". what's going on there? The rest of your settings look fine.

After updating and confirming the frequency try:
1) Erasing the entire chip again.
2) Re-download and flash devo7ebootloader_256.bin. Check that the start address is 0x08000000 and select "Verify after programming".

I hope that works. If it doesn't, try the whole process again but don't jumper the BOOT0 pin. If you are able to connect via st-link without BOOT0 jumped, then you still have the same problem as before where something is pulling BOOT0 pin high.

If this is a modded devo7e, you might have to remove all the other rf modules that you had soldered to the programming header. It could make a difference, cause the modules would draw power from the st-link also (thus turning on) and I'm not sure what logic state the pins will be in while you are trying to flash the processor.

For reference, here is the output I have in my log window from connection to completion of a successful flash.
01:47:57 : ST-LINK SN : 53FF72064967535550252287
01:47:57 : ST-LINK Firmware version : V2J25S4
01:47:57 : Connected via SWD.
01:47:57 : SWD Frequency = 1,8 MHz.
01:47:57 : Connection mode : Normal.
01:47:57 : Debug in Low Power mode enabled.
01:47:57 : Device ID:0x414 
01:47:57 : Device flash Size : 512KBytes
01:47:57 : Device family :STM32F10xx High-density
01:48:02 : [devo7ebootloader_256.bin] opened successfully.
01:48:02 : [devo7ebootloader_256.bin] checksum : 0x9585D497 
01:51:02 : Memory programmed in 3s and 657ms.
01:51:02 : Verification...OK
  • HappyHarry
  • HappyHarry's Avatar
04 May 2016 16:46
Replied by HappyHarry on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

ok i'm really stuck this time, here's my workflow

board was already without an mcu and the pads wicked clean

1: prepped and soldered in the the new mcu
2: fully checked for good solder and no bridges
3: soldered wires to debug header and boot0 jumpers
4: hooked up boot0 jumper, and connected the debug header to the stlink as so
TX       STLink
Vdd      3.3V
Gnd      Gnd
TCK     SWCLK
TMS     SWDIO
5: started the stlink software as an admin
6: plugged the stlinkv2 into the pc
7: connected to the device
8: erased the chip
9: flashed the 256k boot bin
10: compared the file to the flash
11: clicked disconnect in the software
12: removed boot0 jumper, disconnected stlink, reassembled the tx
13: connected the tx usb to the pc, held down ext and turned on the power
14: no lights, no usb device appearing, nothing :/

here's some pics i took of the process.

stlink first connected after soldering
File Attachment:


the settings for the stlink
File Attachment:


the available option bytes
File Attachment:


and the core panel once the device has been flashed
File Attachment:


here's the log file of me connecting the device, checking the 256k boot file against the mcu's memory, and running a checksum against both to be sure they match.
17:09:29 : ST-LINK SN : 56FF71064965565045310487
17:09:29 : ST-LINK Firmware version : V2J24S4
17:09:29 : Connected via SWD.
17:09:29 : SWD Frequency = 1.8 MHz.
17:09:29 : Connection mode : Normal.
17:09:29 : Debug in Low Power mode enabled.
17:09:29 : Device ID:0x414 
17:09:29 : Device flash Size : 384KBytes
17:09:29 : Device family :STM32F10xx High-density
17:09:50 : [devo7ebootloader_256.bin] opened successfully.
17:09:50 : [devo7ebootloader_256.bin] checksum : 0x9585D497 
17:10:03 : No difference found.
                   This file is already downloaded.
17:10:14 : [0x08000000:0x08003000] Memory checksum : 0x9585D497

sorry for the long post but i'm totally stumped, can anyone give me some idea of how to debug this at all? is there some other component that could be damaged on the board that would cause this? does the 7e programming mode work properly with USB3 and 3.1? as i said i'm stumped :/
  • PhracturedBlue
  • PhracturedBlue's Avatar
03 May 2016 04:49
Replied by PhracturedBlue on topic Radiolink AT9 as a platform for Deviation?

Radiolink AT9 as a platform for Deviation?

Category: Development

Here we go. Deviation running on an AT9:


I used PBM image format (same as for the F12E) so each image is only 2 colors, but I added a small extension that allows setting the foreground and background colors for each image. I then converted the Devo8 bmp files into pbm with imagmagick.

The filesystem is devofs running on the upper 256kB of the MCU. It currently takes up 61kB.
I have the rotary encoder working properly and mapped to left/right. there is no way to do a long-press on left/right, and there is no up/down, so I've temporarily mapped the trim up/down to the Up/Down buttons

The filesystem is currently read-only because If a write goes bad it could overwrite the bootloader. Once I back that up, I'll work on enabling write.

So basic functionality is now there. No protocol support yet. Figuring out how to control the interface with only 5 buttons will be the big deal. One trick would be to convert the rotary encoder from left/right to up/down when Mode is also down. IT would work, but I don't really like it.
  • PhracturedBlue
  • PhracturedBlue's Avatar
30 Apr 2016 04:00
Replied by PhracturedBlue on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

I think openocd is what I used last time. It has been a few years though. Here is what appears to be a reaosnable tutorial:
visualgdb.com/tutorials/arm/st-link/
You don't need to get too far into the bootloader to see if it is working or not.

you should check that the boot0 pin is pulled low. in fact you could just short the non-Vdd side to Vss. Not being shorted high is not sufficient. any cap on the pin during bootup can pull it high long enough to enter programming mode. (you could also tie it low through an ammeter and see if there is any current draw. there should be no current on the BOOT0 pin.

If you can get a connection to the STlink with the boot0 jumper removed, than BOOT0 is your culprit. It is theouretically possible to have internal latch-up that would cause this permanently, but I find it quite unlikely.
  • victzh
  • victzh's Avatar
29 Apr 2016 22:46
Replied by victzh on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

As far as I understand - as soon as target is acquired by ST-Link software it stops running the code. To run the code while connected you need to connect from debugger, not from programmer (which ST-Link software is). No other method except usual Devo's method exist - to "see" the TX from DfuSe it should expose DFU device over the USB. For this bootloader should take control and for this it needs to see EXT button pressed.

How did you find that your boot0 is not pulled up to Vcc? By visual inspection or by using meter?
  • silpstream
  • silpstream's Avatar
29 Apr 2016 20:42
Replied by silpstream on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

I believe PB is right that you have a short on your boot0 pin to vcc. I tried shorting boot0 to vcc on my 7e and the power switch won't turn things on, but the power jumper does and it drops straight to stm's built in uart bootloader. When it is in this bootloader, you will not see anything light up on the lcd.

Use a multimeter to check the two boot0 jumper pins above the programming header. You'll probably find that it is shorted. Try tracing that cause it might not necessarily be a short at the processor pins. If your 7e was modded before, you could have wires connected that is causing the short. Take some clear close up pics and maybe we can see more.

You can also use a multimeter and probe the boot0 pin (pin 60) to the few adjacent pins next to it for shorts. Vss is only 3 pin away (pin63) and the short could be under the processor pins if you had too much solder paste.

You should be on the right track so don't give up! :cheer:
  • silpstream
  • silpstream's Avatar
29 Apr 2016 13:01
Replied by silpstream on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

Wasn't actually worried about the pins needed for programming cause we know that works. But beyond those and the USB, we would want to look at the LCD pins. Potentially also any others that the walkera bootloader might check for (if any like the power control pins). I'm not too familiar with the bootloader, but if everything is starting at 0x08000000 like PB said, then eliminating hardware issues will help.

Another check to do is the vreg. Make sure you are getting 3v3. The vreg and electrolytic cspacitors are pretty close to the processor. Could have taken some damage in the replacement. You won't be able to tell when using st-link if your programmer provides power during programming.

;)
  • PhracturedBlue
  • PhracturedBlue's Avatar
29 Apr 2016 12:42
Replied by PhracturedBlue on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

I'm skeptical of bad solder joints, since the only one you need for the bootloader are the usb pins and power and ground (and you already know power & ground are ok, or you couldn't program). The MCU should automatically go into programming mode as soon as it doesn't see any loaded firmware. But definietly sheck the 2 traces that go to the USB port.
  • PhracturedBlue
  • PhracturedBlue's Avatar
29 Apr 2016 03:06
Replied by PhracturedBlue on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

the process sounds fine, and it sounds like you have the chip properly programmed. you are sure you are installing at 0x08000000? haven't used the stlink for a long time, but it is possible to step through execution at a specific address, and it should be clear pretty quicly whether the code is in the bootloader or not (PC address should stay < 0x08003000). I haven't done this for a long time, and am describing this from memory.
  • HappyHarry
  • HappyHarry's Avatar
29 Apr 2016 00:24
Replied by HappyHarry on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

well first time round I didn't jumper the boot pins or the power bypass pins (forgot to do it tbh), also the battery (and back half of the tx) was disconnected, and yet I was still able to connect to and flash the chip ok, I presume this is because the stlink was providing 3.3v, but this left me unable to boot etc.

I then reread the process and began again, so I jumped the boot pins, connected 3.3v, gnd, clk, and sdio to tls, tck, gnd and vcc pins, booted the stlink software as an admin and then plugged in the stlink, I then jumped the power bypass pins and clicked connect to device. once connected I erased the chip, flashed the bootloader and then checked the system memory against the file and all was ok. then I disconnected the decice from the software, pulled the stlink from the pc, removed the 2 jumpers and the stlink wires from the tx. then reassembled and tried to boot to flash deviation. but I was in the same situation as the first time, no power up, no connection to the pc, no lights etc.

is this the correct process? do I need to remove the boot and or power jumpers at a different point, or keep them connected whilst trying to flash deviation?

my stlink in only a 10pin version so is there some site I can go read that will give me some info on how to debug this using it?
  • PhracturedBlue
  • PhracturedBlue's Avatar
28 Apr 2016 22:49
Replied by PhracturedBlue on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

did you leave the chip in boot mode? it sounds like it is booting directly to the internal bootloader. you can debug with the stlink, to see what address is running in theory
  • HappyHarry
  • HappyHarry's Avatar
28 Apr 2016 22:35
Replied by HappyHarry on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

ok i replaced the processor in the first of the 7e's i'm doing and all went well up to a point, the chip swap went ok, i have no solder bridges, i then followed slipstreams bootloader flashing process (which differs slightly from others re pins connected to the programmer etc) and the chip seems to have been flashed ok. here's the log from the stm software
23:27:54 : ST-LINK SN : 56FF71064965565045310487
23:27:54 : ST-LINK Firmware version : V2J24S4
23:27:54 : Connected via SWD.
23:27:54 : SWD Frequency = 1,8 MHz.
23:27:54 : Connection mode : Normal.
23:27:54 : Debug in Low Power mode enabled.
23:27:54 : Device ID:0x414 
23:27:54 : Device flash Size : 256KBytes
23:27:54 : Device family :STM32F10xx High-density
23:28:02 : Flash memory erased.
23:28:17 : [devo7ebootloader_256.bin] opened successfully.
23:28:17 : [devo7ebootloader_256.bin] checksum : 0x9585D497 
23:28:27 : Memory programmed in 3s and 417ms.
23:28:27 : Verification...OK
23:28:41 : No difference found.
                   This file is already downloaded.
23:28:46 : Disconnected from device.

that shows an erase, flash of the 7e256 bootloader and then a compare of the device memory to the file and all passes ok.

but now i can't get the tx to come up at all, turning on the power button does nothing, no lights etc, it wont boot into flash mode or usb mode either.

my method is as slipsreams site, is there something i'm missing? is there any way to debug this?
  • PhracturedBlue
  • PhracturedBlue's Avatar
24 Apr 2016 01:57
Replied by PhracturedBlue on topic Radiolink AT9 as a platform for Deviation?

Radiolink AT9 as a platform for Deviation?

Category: Development

Small update:
I figured out that the problem with uploading to the Radiolink using 'dfu-util' is that the flash has a 2k page size, but the bootloader only supports a 1k transfer-size. dfu-util does an erase/write for each transfer, which means we erase the page we just wrote every other time. The fix is to do an erase pass first, and then follow it up with a write pass. I've modified my dfu_util to do this, but I'll need to update deviation_upload to support this as well to make it easy for others to use. In the interim, the radiolink software is (barely) usable.
  • silpstream
  • silpstream's Avatar
17 Apr 2016 08:34 - 17 Apr 2016 08:35
Replied by silpstream on topic Ultimate7e tutorial: Processor upgrade

Ultimate7e tutorial: Processor upgrade

Category: Tutorials

HappyHarry wrote: it's no problem, i used to make builds available with the extra items enabled (layout editor, permanent timer and telemetry) when we had the code space and i had it set up as a bash script ran weekly so it would be no issue turning that back on and modding the script to make the needed changes etc and then post the builds here or host them somewhere.


Sounds good. We could possibly have it downloadable from the wiki if that's allowed. If not I assume you've forked the Git repository and we could possibly use the "releases" section. Also, any chance I could get a look at that bash script you have? Thanks!

mwm wrote: BTW, we now have a user-editable wiki that includes a hardware mod section. If you could move this tutorial into that, it would stay a lot easier for people to find!


I'll take a look at the wiki and put something in.

SeByDocKy wrote: I think I will go for this mod if I can install/recompile easily the last NB/or test sources. As far I understood, after this MCU mod, flashing a new bootloader, I am able to recompile the deviaition TX with the devo7E-256 target?


Yes.
make TARGET=devo7e-256
Works as of commit 3435a2a.
Displaying 241 - 260 out of 542 results.
  1. Forum
  3. Search
Time to create page: 0.976 seconds
Powered by Kunena Forum
Force desktop display