Writing application for Stm32F105 @ 25 MHz

[Bigpie]

Will this bootloader work on a STM32F105?
Want to attempt to run one of the cheap aliexpress can bridges with the openinv ecosystem https://dangerouspayload.com/2020/03/10 ... er-device/

[johu]

Yes. Just have to pay attention to use the correct UART and CAN perhaps with the correct pin remap

[Mitchy]

Will this bootloader work on a STM32F105?
Want to attempt to run one of the cheap aliexpress can bridges with the openinv ecosystem https://dangerouspayload.com/2020/03/10 ... er-device/

You may need to swap the crystal (or modify the code for 25 MHz)
Currently have a few crystals in my mouser cart, waiting until I get enough random parts cached up to qualify for free shipping

I can confirm the bootloader works with the F107 64 pin parts as well; however to get zombie code working, it seems you need to disable a call to GPIO E ports, in case you're looking to do something similar.

[johu]

The boot loader uses the internal oscillator
you want to write a bootloader based on template? Or your app?

The app you can of course modify to 25 MHz. It's just important that the core frequency remains at 72 MHz because CAN relies on it. But as far as I remember from the Olimex proto board that is sorted

[Bigpie]

I want to use the template to make a can gateway so that I can update it over can. I've got the bootloader running on it now. Moved to UART 4. Next up hello world with template

[Bigpie]

Code: Select all

#define RCC_CLOCK_SETUP() rcc_clock_setup_in_hse_25mhz_out_72mhz()

I'm not all that familiar with the lower level stuff, but I guess it's needs more than this to configure.

[royhen99]

That should work. I run STM32F105 with 16MHz clock and that is all that is needed, if not using the RTC.

[Bigpie]

Must have messed something up then, though the bootloader is working, and can flash my app, but once it boots the uart isn't working.

I've updated the Terminal to use UART 4 and

Code: Select all

 { UART4,  DMA2, DMA_CHANNEL5, DMA_CHANNEL3, GPIOC, GPIO_UART4_TX,  GPIOC, GPIO_UART4_RX },

Probably off topic for this thread now though

[royhen99]

For UART4 you also need to enable DMA2 clock in hwint.cpp

rcc_periph_clock_enable(RCC_DMA2);

[Bigpie]

Got it working on the UART web interface now, thanks, that did it.

[Bigpie]

Got a strange issue in that the update get stuck at 5%. Any pointers as to where to look?

[johu]

Not quite sure, is it complaining about crc? It asks for it and afterwards something seems to go wrong. CRC clock enabled? What do you use to send the update?

[Bigpie]

Just using the esp32 webui can backend, that works with other nodes so should be ok.
https://github.com/jamiejones85/stm32-C ... /BlueBoard is what I've changed so far. The CRC clock is enabled

[johu]

Now back on my computer. Looked at the log a bit closer.

So we see a couple of hello messages in the beginning, apparently there is no valid firmware in flash. Then we see the reset command to node id 0x2D. Then another hello message, then the update trigger, request for size (0x53) which is answered with 0x14, then request for the page (0x50), answered with 8 bytes of binary data. This repeats 21 times but should repeat 128 times. So there's the problem.

Subsequently we see request for CRC (0x43) answered with some CRC and then CRC error (0x45). Now weirdly again request for CRC while really we'd want to see request for page (0x50). So something really goes wrong with the sequencing.

Maybe the CAN link is really bad and many frames are lost?

[Bigpie]

There's no firmware on, it boots in to firmware and gives params if I flash the bin with stlink. https://github.com/jamiejones85/stm32-CANBridge
It's pretty strange, I can use the UART to flash if there's no firmware on there, but once theres firmware it wont flash with UART, just hangs at Upload Complete, manually restarting the stm32 doesn't kick off the update.

editing out the CRC check doesn't complete the flashing either.

Code: Select all

case CRC:
      currentWord = 0;
      crc_reset();
      // if (words[0] == crc)
      // {
         numPages--;
         if (numPages == 0)
         {
            state = DONE;
         }
         else
         {
            state = PROGRAM;
         }
      // }
      // else
      // {
      //    send_byte('E');
      //    state = PAGE;
      // }
      break;

I'm wondering, given its price and source, that the STM32 might be a fake?

[johu]

It would then work pretty well for a fake... In the schematic it seems like nothing is connected to the Rs pin of the transceivers so it would essentially be disabled. Which it isn't but maybe it doesn't work well like that? Try grounding Rs (Pin 8)

[royhen99]

The schematic above is for the "green board" and it looks like pin 8 is actually connected to 0V. The blue board uses TJA1042, pin 8 is standby and also appears to be connected to 0V on the board.

[Bigpie]

So using the python script when there's firmware on there:

Code: Select all

python updater.py --device /dev/tty.wchusbserial1420 --file ~/code/stm32-CANBridge/stm32_canbridge.bin 
File length is 19992 bytes/20 pages
Resetting device...
Sending number of pages...
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 

Do a full chip erase and put just the boot loader on

Code: Select all

File length is 19992 bytes/20 pages
Resetting device...
Version 2 bootloader, sending magic
Sending number of pages...
Sending page 0... CRC correct!
Sending page 1... CRC correct!
Sending page 2... CRC correct!
Sending page 3... CRC correct!
Sending page 4... CRC correct!
Sending page 5... CRC correct!
Sending page 6... CRC correct!
Sending page 7... CRC correct!
Sending page 8... CRC correct!
Sending page 9... CRC correct!
Sending page 10... CRC correct!
Sending page 11... CRC correct!
Sending page 12... CRC correct!
Sending page 13... CRC correct!
Sending page 14... CRC correct!
Sending page 15... CRC correct!
Sending page 16... CRC correct!
Sending page 17... CRC correct!
Sending page 18... CRC correct!
Sending page 19... CRC correct!
Update done!

Then try flashing again

Code: Select all

File length is 19992 bytes/20 pages
Resetting device...
Sending number of pages...
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 
Sending page 0... 

"Version 2 bootloader, sending magic is" is the obvious difference, now to workout why.
I've dumped the memory for both and the bootloader remains the same, but not getting any UART output (22222...) once the firmware is on there.

[johu]

Maybe it's not taking the reset command.
If you open a console and send "reset" do you get the "2" output once?
Likewise if you send the reset command via CAN (just copy the 0x62D message from your log earlier)

Otherwise it's normal it stops 2222ing because once and application is on there it isn't constantly resetting

[Bigpie]

No, I don't get the single 2 and no response to the reset or json command. Very strange.

[johu]

So something is fishy with the terminal?

Just wondering, where is libopeninv in your project? Have you made any changes to it?

Also surprised you had to manually add UART4 to the terminal as it's already in there in the most recent version (and tested with Olimex STM32-P107)

[Bigpie]

Still digging at this,

So if I've got just the bootloader on using openocd/gdb to step though, everything executes as expected.

If theres any firmware, then in the bootloader hwinit.cpp in can_setup() on the line nvic_enable_irq(NVIC_USB_LP_CAN_RX0_IRQ); it seems reboots.

And this is without firmware

[Bigpie]

Ok so the bootloader is too large.

Need to shrink it.

[WillK]

I've been playing with the blue board too, managed to follow Jamie's work successfully

- Built the bootloader from https://github.com/jamiejones85/stm32-C ... /BlueBoard

- uploaded to blue board using an stlink v2 (a bit of faffing there, but with combination of stm32cube & blackmagic debug app got it flashed using the SWD connection)

- bootloader as built was sub 4k (3988 bytes) so didn't experience the issues above.

- built Jamies CANBridge demo app at https://github.com/jamiejones85/stm32-CANBridge (just need a couple of missing git submodules to build)

- uploaded to blueboard over CAN using the esp32 webui on lilygo (https://github.com/jamiejones85/esp32-w ... ilygo_tcan)

- success - CAN messages on each blueboard interface, persists through power cycles,

i've still a lot to learn about the OI ecosystems, and not really figured out how nodeIds are assigned yet.

Fantastic work Jamie, think this will be a really useful and very cost-effective little board for CAN bridge /filter/ MITM.

[Mitchy]

Just want to say thanks to Jamie for pulling this together.

Confirmed the above links and instruction from WillK work to get started.

• Compiled Bootloader from 'BlueBoard' repo - No size issues, compiled using LinuxMint

• Flashed Bootloader, but needed to use CubeProgrammer to disable flash lock, after which could wipe chip, used windows for this.

• Compiled the Can-Bridge code using LinuxMint - All good

• Confirmed Web Interface operational

• Continued to Steal Zombie and Simp code (thanks Tom & Jon Volk) to hack together a "functional" Volt/Ampera Gen1 BMS controller

Hoping to leverage this to make a interface for the VW chargers next.


One query I have is after programming/flashing, I need to fully power cycle things before SDO/CAN come back.
Likely some Init is missing, but if anyone noticed a similar issue and has a fix, would save me some time in trial and error.