2013-11-15 07:01 AM
The native CAN bootloader of STM32F107, revision Z, date code 244,
produces many faulty messages. Peak CAN controller to communicate with the bootloader via CAN reports various errors as RX frame, TX frame errors, etc. The general working scheme as described in the CAN bootloader app note works, however accessing the CPU is not really working due to the massive bus faults. Any hardware issues are ruled out since the identical CPU with the identical hardware works while using own software running on the STM32F107 to communicate over the CAN bus. Also using the speed command (ID=0x03) does not help. Is there any other solution to solve this issue than writing our own CAN bootloader? CAN bus is a must in our application. The built in bootloader would be very handy since it can't be destroyed. Any help very appreciated. Best regards, Sebastian #can-bootloader-stm32-stm32f105 #bootloader #can #stm322013-11-25 11:47 AM
Dear all,
is there anybody out there who can tell me a success story on flashing STM32F107 via the internal bootloader? Best regards, Sebastian2013-11-25 11:58 AM
The pool of experts here is pretty shallow. I've used the boot loader, not with CAN
2015-09-17 11:22 PM
Hi Sebastian,
I know, the Thread is very old, but I HAD the same problem. The solution tooks me like two Weeks to find! It's the Bit-Timing register on the PEAK PCAN Dongle, or better said: the sampling point. If you choose the standard settings from the peak api the sampling point on the 125k Baud is set to 87.5% (standard on CANopen and so on...). But in the case of the Bootloader of the STM32F105/7 I found out, that this standard sampling point isn't correct in every case and you get lots of frame errors or endless retransmissions of CAN messages. The sampling point (and also the baudrate) is set in the BTR0BTR1 register of the PEAK PCAN dongle, well known as the TPCANBaudrate parameter in the CAN_Initialize method. In my case, a sampling point at 50% has done the work! I get the sampling point settings from the PCAN Viewer. If you connect in the viewer with a can dongle, you can change the baudrate settings,, by clicking on the arrow button next to the baudrate dropbox. There is a Bitrate-Settings window where you can create a new baudrate and then playing around with the prescaler, the first and second segment and also the syncronization width. By changing one of these settings the Bus-Timing-Register value (below the settings) is also changing. When you get the 50% sample point (in my case prescaler: 4, segm1: 7, segm2: 8 and sync:1) you have the needed value of the bus timing register (my case 0x0376). All what you have to to now, is use this value as baudrate by casting it to TPCANBaudrate in the initialize method of the peak api: CAN_Initialize(Hande, (TPCANBaudrate)0x0376). After that everything has worked for me and I never gets a frame error again. Have a nice Day! Alain2016-05-06 03:26 PM
Hello,
I'm also experiencing programs with internal bootloader. I cannot connect to bootloader with my master USB-CAN device based on STM32F105. Slave STM32F105 controller does not respond to 0x79 message. Moreover when I connect MHS Tiny-CAN logger instead of my master device and send 0x79 message from logger, slave controller acknowledges first message and enters CAN bootloader. After that I reconnect my master USB-CAN adapter and then communication with booloader works. The setup of my system is: about 60cm of CAN cable taken from automotive wiring harness, terminated in both ends with 120 Ohm resistor. 3.3V can transceivers SN65HVD233. Slope control pin is wired to GND through 10 kOm resistor, loopback pin wired to GND. Both processors run on 8 Mhz quarz. When watching signals with oscilloscope I see that MHS logger makes about 500 mV higher signal difference in dominant state than my USB-CAN adapter. Nevertheless when I check signal going from transceiver to processor on my slave device I can't find any difference. Also timing looks also the same. Where could be the magic?