openinverter forum

While I work on the schematic for my mainboard, intended to work with the Honda IMA inverter for an electric motorcycle, I'm also trying to get acquainted with the software by simply loading it onto the Olimex STM32-H103 board. I have Dima's front end on my computer, using the Xampp stack, and it seems to start up just fine, but it can't find any serial data stream coming in. I've flashed firmware ver 4.17.R, and when I power up the Olimex, the green LED is flashing, so it seems at least the ISRs are running. Upon checking the USART3 TX line (PB10) with my 'scope, I see it goes high when I power up the board, and then just stays high - no data stream coming out.

Now I thought I remembered from the original DIYElectricCar thread that there is some logic in the startup code to make sure the rest of the hardware is there, and nothing is in a failed state. If something shows as failed, the code won't complete its initializations, and will end up in this state. But I can't find that post now (Talk about an epic thread!). So I set up some voltage dividers, pull-ups, and pull-downs, to "fake out" the firmware. Here's what I've got - what am I missing?

I_L1 (PA5) = 1.6V
I_L2 (PB0) = 1.6V
UDC (PC3) = 1.6V
Heat_Sink_Temp (PC4) = 2.1V
EMCYSTOP (PC7) = 3.2V
MPROT (PA3) = 3.2V
FWD (PA4) = 3.2V
BKIN (PB12) = 0.0V
OverCurrent (PA1) = 3.2V
Error_Input (PC9) = 3.2V
UVLO (PA0) = 3.2V

Thanks.

The bootloader only outputs the string "2D" at powerup, after that the serial link is silent. Only when data is requested (e.g. by the "json" command) you will see a reply.
The serial link works regardless of the state of any physical inputs

Well, that explains that. Thanks, Johannes. I think my next step is to drop back to a simple terminal program and get the communication working.

OK, progress. Using PuTTYtel, it appears I'm sending characters. I am getting characters back, and I can see the USART TX line working on my 'scope.

However, I don't get "2D" on power-up, just a single character, "3". And rather than collect the characters I send into a command, I get a new character echoed back immediately after each one I type. For example, if I try to send the command, "all", I immediately get "X" back after "a", and ";" back after each "l". This is using the 9-pin COM1 port on my PC, so it's not an issue of the counterfeit converter in the USB cable.

Thoughts?

ChazFisher wrote: ↑Tue Aug 20, 2019 1:26 am it appears I'm sending characters. I am getting characters back,

Change COM speed to 115200.

Set to 115200 N82 when I got those results.

I dono, sounds like you have not flashed the bootloader properly. Try reflashing with ST-Link viewtopic.php?f=2&t=6

Also if you are using the "other" web-interface don't run it from xampp (there is a lot of background prep work in Windows) - just run .bat file.

OK, I tried reflashing both bootloader and main code. I'm using the Windows GUI from STM, as you showed in your post, dima. It reported back that both hex files verified OK. But I got the same results. I even tried falling back to firmware version 4.10.R - same results.

When I run your batch file, here's where I end up:

PowerShell Version 5

Huebner Inverter - Console Management


Multiple COM detected

COM1
COM3
COM4

Enter COM (Example: COM2): COM1
True
====================================
COM port 'COM1' set in serial.json
====================================

Status for device COM1:
-----------------------
Baud: 115200
Parity: None
Data Bits: 8
Stop Bits: 1
Timeout: OFF
XON/XOFF: OFF
CTS handshaking: OFF
DSR handshaking: OFF
DSR sensitivity: OFF
DTR circuit: ON
RTS circuit: ON

PHP 7.3.2 Development Server started at Tue Aug 20 21:47:51 2019
Listening on http://0.0.0.0:8080
Document root is C:\Users\Charles Fisher\Documents\AC Controller\JHuebner\Frontend\Web
Press Ctrl-C to quit.

And then it just sits there forever. I always end up using Ctrl-C to exit. One funny thing - in that batch file response you see the port status is 115200 and N81. But when I look at the port status in Device Manager, it says 115200 N82. Wonder why would they be different?

Wow this is a mystery ...can you re-download the newest build from github? The multiple COM should show manufacturer description now.

Maybe COM1 is the wrong com.

I'll download the latest hex files this evening. COM1 is the correct port, I see the characters being transmitted with my scope. I saw the same behavior with COM4 as well.

Does the terminal in the STM echo back each character as it is received? I have local echo turned on in PuTTY, so I see the character I type, followed by a different character received back.

The other thing I'll try tonight is a completely different computer for my console.

ChazFisher wrote: ↑Wed Aug 21, 2019 4:57 pm Does the terminal in the STM echo back each character as it is received?

No. It only echos entire command after you press Enter. This is not a Putty setting but inverter programming.

dima wrote: ↑Wed Aug 21, 2019 5:49 pm

ChazFisher wrote: ↑Wed Aug 21, 2019 4:57 pm Does the terminal in the STM echo back each character as it is received?

No. It only echos entire command after you press Enter. This is not a Putty setting but inverter programming.

What does it do with an invalid command? I see the valid commands in termina_prj.cpp.

In fact each character is echoed back immediately.
Invalid command trigger the “Unknown command sequence“ message in terminal.c

johu wrote: ↑Wed Aug 21, 2019 10:17 pm In fact each character is echoed back immediately.
Invalid command trigger the “Unknown command sequence“ message in terminal.c

Ok, interesting. What I'm seeing is a different character being echoed back. Wonder if it's the mismatch between the port setting I saw from Diana's batch file. Definitely goig to try my older laptop this evening.

ChazFisher wrote: ↑Wed Aug 21, 2019 4:57 pm I'll download the latest hex files this evening. COM1 is the correct port, I see the characters being transmitted with my scope. I saw the same behavior with COM4 as well.

Does the terminal in the STM echo back each character as it is received? I have local echo turned on in PuTTY, so I see the character I type, followed by a different character received back.

The other thing I'll try tonight is a completely different computer for my console.

All right, I'm pretty much at wit's end. I downloaded both bootloader and firmware from github, and reflashed the board. Checksums were:
Bootloader: 0x0003769D
Firmware: 0x0031CFAC

Then I loaded PuTTYtel onto my other laptop. Powered up, and still exactly the same behavior. Single character "3" received on power-up. Any ascii character I type in gets a different character echoed back. For example, "a" returns "X", "b" returns "l", "c" returns ",", etc. etc.

In the "desperate times mean desperate measures" department, I even soldered wires directly onto the Olimex board for the USART connections. I just tapped right onto the top of the 26-pin header. Still exactly the same behavior.

Is it possible I got a counterfeit board? I bought it from Digikey, not some unknown source, but who knows. Maybe I should order another and see if it behaves any differently.

This is entirely new for me also. Misinterpreted characters point to a baud rate issue. I wonder if the quartz is faulty? Can you scope the uart TX with a well visible time base and post it here? Or scope the quartz to see if it's 8MHz

I assume your using a usb to serial converter to connect to uart3. Connect the tx and rx pins together on this converter, send characters and see if they echo back, them check the baud with the scope, sending U should be 1010....

I assume your grounds are ok too.

If the inverter is echoing back different characters, the baud rate might be incorrect but you said you already tried 115200 with 2 stop bits. Have you connected the ground of your PC with the inverter ground? Also if your USB to Serial Converter has +5V/GND/RX/TX pins make sure you have +5V unconnected.

All right, here we go. STM32 Usart3-RX (Olimex J2-15) is connected to 9-pin serial pin 3 (RS232-TX). Usart3-RX (J2-14) is connected to 9-pin serial pin 2 (RS232-TX). STM32 Vss (J2-25) is connected to 9-pin serial pin 5 (GND).

Upper trace is Usart3-RX (PuTTYtel transmit), lower trace is Usart3-TX (PuTTYtel receive). I transmitted an "a" to the STM32, puTTYtel reported an "X" echoed back. The Olimex board is powered via the USB port on the board, using a USB phone charger (i.e. power is not coming from the computer).



So what I see is the idle state of the Usart3-TX is high, instead of low. As if it's an open-collector output that floats high. Once the Usart starts to drive the TX line, it's driving the correct waveform, but because it's starting in the opposite logic state, PuTTYtel is interpreting it differently.

Is there some jumper on the Olimex board I've got set wrong? Or is it just a damaged chip? I have to admit, my ESD practices are pretty sloppy here at home.

ChazFisher wrote: ↑Fri Aug 23, 2019 2:31 am All right, here we go. STM32 Usart3-RX (Olimex J2-15) is connected to 9-pin serial pin 3 (RS232-TX). Usart3-RX (J2-14) is connected to 9-pin serial pin 2 (RS232-TX). STM32 Vss (J2-25) is connected to 9-pin serial pin 5 (GND).

Ok, now I get it You're using RS232 on a TTL level uart. Poor Olimex
Basically RS232 outputs a positive voltage for "0" and a negative voltage for "1". You can see the negative voltage is clamped by the ESD diodes, the positive voltage is clamped by some other component to 6V. I hope nothing get damaged. If you still have a blink LED you should be alright.

So what you want is a TTL level (3.3V) serial adapter. Or a wifi module.

johu wrote: ↑Fri Aug 23, 2019 5:04 am

ChazFisher wrote: ↑Fri Aug 23, 2019 2:31 am All right, here we go. STM32 Usart3-RX (Olimex J2-15) is connected to 9-pin serial pin 3 (RS232-TX). Usart3-RX (J2-14) is connected to 9-pin serial pin 2 (RS232-TX). STM32 Vss (J2-25) is connected to 9-pin serial pin 5 (GND).

Ok, now I get it You're using RS232 on a TTL level uart. Poor Olimex
Basically RS232 outputs a positive voltage for "0" and a negative voltage for "1". You can see the negative voltage is clamped by the ESD diodes, the positive voltage is clamped by some other component to 6V. I hope nothing get damaged. If you still have a blink LED you should be alright.

So what you want is a TTL level (3.3V) serial adapter. Or a wifi module.

Ah, I guess I wasn't thinking hard enough when I ordered the USB to serial converter. I do still have the blinking LED. Do you think I could have damaged the TX port, causing the high idle state?

And when I power up the Olimex board with just the scope probes attached, no external serial link, the TX line goes and stays high. So I'm pretty sure I killed it. Just goes to show how long it's been since I did any real design work - I forgot the RS232 standard is not just an encoding scheme, it's also the voltage levels. Ah well, gives me time to work on my board schematic.

Thanks for the help, folks!

Just tested the voltage levels on mine, TX is high in idle state. So you're alright.

Hopefully so. It might just be the fact that the ST32 can't drive the line to a negative voltage, so the receiver gets confused. I've got a USB-TTL cable on the way, so we'll see.

If you have an Arduino Uno, you can remove the ATMEL chip from the board and connect the RX/TX/GND lines to it, and use it's usb port as a usb/serial adapter. Just a suggestion if you already have it, it's pretty common.