openinverter forum

160 ms is about the boot loader wait time.
This is the intended one: https://github.com/jsphuebner/stm32-CANBootloader/

This raises the question whether the pin init is defunct in foccci for some reason. Will investigate when I'm back home

If anyone wants to take a peek
https://github.com/jsphuebner/stm32-CAN ... t.cpp#L128 (pin init commands are executed here)

https://github.com/jsphuebner/ccs32clar ... it.cpp#L72 (and declared here)

Had a look, nothing obvious found so far. Setting the PB1 to high works, so no idea so far why the PB4 gets a pull-up.

Edit: Found a hot candidate. The pull-up of the PB4 starts quite early, ~3.5ms before the PB1 gets high in initialize_pins(). This means, this pull-up seems to come quite early in the start of the bootloader. But in code, I did not find anything. Could it be pull-up per default? Bingo. The data sheet says: This means, the PB4 is configured to alternate function, and that's why the writing of the GPIO during initialize_pins() is pointless.
Solution proposals:
- In bootloader, set the PB4 to GPIO. Not sure whether this is good for the generic bootloader, or needs a project specific configuration.
- This would still lead to a few milliseconds pull-up of the PB4, between releasing the reset and the initialize_pins(). To have a clean reaction, an external pull down on PB4 would help.

Edit2: In https://www.keil.com/dd/docs/datashts/s ... f10xxx.pdf Table 33 they explain that "freeing" the PB4 is confibured in SWJ_CFG[2:0]. The clara application seems to configure this in main() by gpio_primary_remap(AFIO_MAPR_SWJ_CFG_JTAG_OFF_SW_ON, ...) Could this be taken-over into the bootloader?

uhi22 wrote: ↑Sun Jun 16, 2024 5:31 pm Edit2: In https://www.keil.com/dd/docs/datashts/s ... f10xxx.pdf Table 33 they explain that "freeing" the PB4 is confibured in SWJ_CFG[2:0]. The clara application seems to configure this in main() by gpio_primary_remap(AFIO_MAPR_SWJ_CFG_JTAG_OFF_SW_ON, ...) Could this be taken-over into the bootloader?

Yes, that's the reason! Bumped into this before with the version check of the Gen3 Leaf board. Will add this to the boot loader

Boot loader fixed: https://github.com/jsphuebner/stm32-CAN ... s/tag/v1.1

johu wrote: ↑Sun Jun 16, 2024 3:23 pm This is the intended one: https://github.com/jsphuebner/stm32-CANBootloader/

Is this intended for Zombie also, as both bootloaders works for both boards now that I tested?

evMacGyver wrote: ↑Thu Jun 20, 2024 12:03 pm Is this intended for Zombie also, as both bootloaders works for both boards now that I tested?

not 100% sure if it'll work as is over CAN with Zombie. It uses non-remapped CAN1 and one of Damiens projects uses remapped CAN1. Dont exactly remember which one.

We are currently in France and we use a Peugeot 208 loaner. I want to express my disliking of coupling the remote control to the charging control.
So today I AC charged the car while I went for a walk. When I came back the car still wasn't full so I decided to sit in it and wait a few more minutes. When I opened it charging was interrupted and this exited the session as well! This sucks even more when there is a starting fee which is not uncommon when paying with credit card.

I saw a car maniac video where he went to check around midnight if the car was still charging. By opening the car he must have also interrupted the session but didn't notice it. So the next day the car was at 50% or something.

Stopping charging should be a very explicit operation and not coupled to some random operation of the car in my opinion.

I'm happy with the concept of Hyundai Ioniq. While AC charging, if the user pushes unlock on the remote key or on the inner door panel, the OBC reduces the power to zero for 10s and unlocks the connector for the same time. I think it does not change from state C to state B, so the charger does not detect the end of the session. Charging just continues after the 10s, if the user does not pull the plug during this time.

uhi22 wrote: ↑Wed Sep 18, 2024 5:26 am The OBC reduces the power to zero for 10s and unlocks the connector for the same time. Charging just continues after the 10s, if the user does not pull the plug during this time.

Interesting, BMW do a similiar things but I believe they actually shut down. You still need a way of getting this info to the Foccci, I would suggest a new OBCstate for this specific scenario and let a VCU or vehicle integration ecu deal with this.

I try to understand the wakeup circuit.
The EN pin of the TPS54302 (U4) needs ±1.3V to power on. And it accepts absolute max 7V.
What does the 40V Schottky Barrier Diodes 1N5819WS (D8) with the 12V wakeup signal?
I would expect a voltage divider or an opamp circuit to limit the voltage for the EN pin.

D8 ensures that EN is never driven high by anything. It has an internal pull-up. The various wakeup signals can allow that pullup to actually pull EN high. If no wake up source is active EN is forced low by R56