Unable to verify firmware functionality using Putty

[mikaelhaji]

Description: I am having trouble verifying the functionality of the firmware on my USTX board using Putty. I have successfully programmed the firmware using the .elf file that loaded in the Binaries directory and the SEGGER J-Link debugger. However, I am unsure how to proceed with testing the firmware (either with or without Putty).

The README file mentions that a green indicator light should start flashing after successful programming, but in my case, the green light was flashing before programming and stopped after the debugging session.

Before the Debugging Session: Video

I have opened Putty and tried to establish a serial connection using the COM ports listed in device manager (not even sure if its being picked up through the COM Port), but I am not seeing any output or expected behavior.

Here is the session console log:

SEGGER J-Link GDB Server V7.94h Command Line Version

JLinkARM.dll V7.94h (DLL compiled Feb  1 2024 11:04:36)

Command line: -port 2331 -s -device STM32F446RC -endian little -speed 4000 -if swd -vd
-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      localhost only
Generate logfile:              off
Verify download:               on
Init regs on start:            off
Silent mode:                   off
Single run mode:               on
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 STM32F446RC
Target device parameters:      none
Target interface:              SWD
Target interface speed:        4000kHz
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V12 compiled Jan 24 2024 12:06:13
Hardware: V12.00
S/N: 52007717
Feature(s): GDB
Checking target voltage...
Target voltage: 1.77 V
Listening on TCP/IP port 2331
Connecting to target...
Halting core...
Connected to target
Waiting for GDB connection...Connected to 0000:0000:0000:0000:0000:0000:0000:0001
GDB client (conn. 984) requested target.xml from GDB Server
Reading common registers: Read register 'r0' (4 bytes) from hardware: 0x01000000
Read register 'r1' (4 bytes) from hardware: 0x08000000
Read register 'r2' (4 bytes) from hardware: 0x01000000
Read register 'r3' (4 bytes) from hardware: 0x01000000
Read register 'r4' (4 bytes) from hardware: 0xC0030020
Read register 'r5' (4 bytes) from hardware: 0x00000000
Read register 'r6' (4 bytes) from hardware: 0x00000000
Read register 'r7' (4 bytes) from hardware: 0xC8FF0120
Read register 'r8' (4 bytes) from hardware: 0x00000000
Read register 'r9' (4 bytes) from hardware: 0x00000000
Read register 'r10' (4 bytes) from hardware: 0x00000000
Read register 'r11' (4 bytes) from hardware: 0x00000000
Read register 'r12' (4 bytes) from hardware: 0x000000E1
Read register 'sp' (4 bytes) from hardware: 0xC8FF0120
Read register 'lr' (4 bytes) from hardware: 0xE1060008
Read register 'pc' (4 bytes) from hardware: 0xE6060008
Read register 'xpsr' (4 bytes) from hardware: 0x00000021
Read 4 bytes @ address 0x080006E6 (Data = 0x429A68FA)
Reading register 'msp' = 0x2001FFC8
Reading register 'psp' = 0x00000000
Reading 64 bytes @ address 0x2001FFC0
Read 4 bytes @ address 0x080059F8 (Data = 0x681B4B0B)
Received monitor command: ReadAPEx 0x0 0xF8
O.K.:0xE00FF003
Received monitor command: ReadMemAP 0x0 0xE00FFFD0 0x8 0x0
O.K.:0x00000000,0x00000000,0x00000000,0x00000000,0x00000011,0x00000004,0x0000000A,0x00000000
Connected to 0000:0000:0000:0000:0000:0000:0000:0001
GDB client (conn. 1004) requested target.xml from GDB Server
Reading common registers: Read register 'r0' (4 bytes) from hardware: 0x01000000
Read register 'r1' (4 bytes) from hardware: 0x08000000
Read register 'r2' (4 bytes) from hardware: 0x01000000
Read register 'r3' (4 bytes) from hardware: 0x01000000
Read register 'r4' (4 bytes) from hardware: 0xC0030020
Read register 'r5' (4 bytes) from hardware: 0x00000000
Read register 'r6' (4 bytes) from hardware: 0x00000000
Read register 'r7' (4 bytes) from hardware: 0xC8FF0120
Read register 'r8' (4 bytes) from hardware: 0x00000000
Read register 'r9' (4 bytes) from hardware: 0x00000000
Read register 'r10' (4 bytes) from hardware: 0x00000000
Read register 'r11' (4 bytes) from hardware: 0x00000000
Read register 'r12' (4 bytes) from hardware: 0x000000E1
Read register 'sp' (4 bytes) from hardware: 0xC8FF0120
Read register 'lr' (4 bytes) from hardware: 0xE1060008
Read register 'pc' (4 bytes) from hardware: 0xE6060008
Read register 'xpsr' (4 bytes) from hardware: 0x00000021
Read 4 bytes @ address 0x080006E6 (Data = 0x429A68FA)
Reading register 'msp' = 0x2001FFC8
Reading register 'psp' = 0x00000000
Reading 64 bytes @ address 0x2001FFC0
Read 4 bytes @ address 0x080059F8 (Data = 0x681B4B0B)
Received monitor command: reset
Resetting target
Downloading 452 bytes @ address 0x08000000 - Verified OK
Downloading 16080 bytes @ address 0x080001D0 - Verified OK
Downloading 14840 bytes @ address 0x080040A0 - Verified OK
Downloading 1940 bytes @ address 0x08007A98 - Verified OK
Downloading 8 bytes @ address 0x0800822C - Verified OK
Downloading 4 bytes @ address 0x08008234 - Verified OK
Downloading 4 bytes @ address 0x08008238 - Verified OK
Downloading 124 bytes @ address 0x0800823C - Verified OK
Writing register 'pc' = 0x08006090
Starting target CPU...
GDB closed TCP/IP connection (Socket 1004)
Debugger requested to halt target...
...Target halted (PC = 0x0800069E)
Reading common registers: Read register 'r0' (4 bytes) from hardware: 0x03000000
Read register 'r1' (4 bytes) from hardware: 0x02000000
Read register 'r2' (4 bytes) from hardware: 0x02000000
Read register 'r3' (4 bytes) from hardware: 0x01000000
Read register 'r4' (4 bytes) from hardware: 0xC0030020
Read register 'r5' (4 bytes) from hardware: 0x00000000
Read register 'r6' (4 bytes) from hardware: 0x00000000
Read register 'r7' (4 bytes) from hardware: 0xC8FF0120
Read register 'r8' (4 bytes) from hardware: 0x00000000
Read register 'r9' (4 bytes) from hardware: 0x00000000
Read register 'r10' (4 bytes) from hardware: 0x00000000
Read register 'r11' (4 bytes) from hardware: 0x00000000
Read register 'r12' (4 bytes) from hardware: 0x000000E1
Read register 'sp' (4 bytes) from hardware: 0xC4FF0120
Read register 'lr' (4 bytes) from hardware: 0xE1060008
Read register 'pc' (4 bytes) from hardware: 0x9E060008
Read register 'xpsr' (4 bytes) from hardware: 0x00000021
Read 4 bytes @ address 0x0800069E (Data = 0x4B03AF00)
GDB closed TCP/IP connection (Socket 984)
Restoring target state and closing J-Link connection...
Shutting down... 

I would appreciate any guidance or suggestions on how to troubleshoot this issue and successfully test the firmware. Let me know if you need any additional information!

Edit: A detailed video on the issue we are dealing with and the strange activity observed. Previously, when adding in the USB C cable, the green light would blink. Was not reproducible in the video. Thanks!

[mikaelhaji]

Figured it out! Seems we just had a finicky j-link base. We have a flashing green light after pressing down on the cable and also got these popped up in the PuTTY terminal:

This seemed to have popped up as the PuTTY was open when deploying the build. Following this, any command like "ping" or a random character just returned "unknown command" which I'm guessing is not a horrible sign that there is at least some type of communication - not sure if i should expect something else.

[mikaelhaji]

Update: Seems this is the expected output at this stage.

Was able to find the onda executable and run:

ustx-onda <json file> <COM port number>

• with the example json on the github
• the output looks like the following:

C:\Users\mikae\USTX\opw_ustx\application\ustx-onda\msvc\x64\Debug>ustx-onda.exe C:\Users\mikae\Downloads\fus.json 8
Sending Hex file, estimated time: 0 seconds
__________________________________________________
##################################################
Download Successful
Focus Delay: 21.2us
Set Focus: 4
Invalid Focus, max focus: 2
Set Focus: 2
Focus now at 10.0mm, 10.0mm
Delay: 11.8us
Set Focus: 1
Focus now at -10.0mm, 10.0mm
Delay: 11.8us
Set Focus: 2

[georgevigelette]

Hi Mikael,

I was setting up the USTX v1 to help guide you with the bring up and yes that looks like the correct output for the test JSON. Adding a trigger signal to the trigger BNC connection and a inhibit signal to the inhibit BNC will trigger the profile to run and generate the waveforms out on the transducer connector. The trigger signal will start the profile and the inhibit just enables or disables the trigger.

[mikaelhaji]

Hi George! Thank you so much for your message. We are now attempting to read the signal being emitted through the board using an Oscilloscope and are running into some issues on that end (was going to make a new issue as I realized this one might have been getting too long haha).

Here are some pictures demonstrating our current setup right now:

We basically deployed the json file that was on the read me to the board and was hoping to then pick up on a signal from the Oscilloscope.

Currently, we are feeding a 500khz square wave to the trigger and then the command we are running is the following:

C:\Users\mikae\USTX\opw_ustx\application\ustx-onda\msvc\x64\Debug>ustx-onda.exe C:\Users\mikae\Downloads\fus.json 8

My current topics of confusion include (which might be causing the lack of ability to validate it through the scope):

1. Is there something I am supposed to connect to the inhibit port?
2. What exactly is this input asking for? Should I be keeping the board plugged into the computer to constantly be inputting this number?

Set Focus: 2
Focus now at 10.0mm, 10.0mm

3. The board has been flashing green but just a few mins ago also introduced a red light (which from my understanding is a very bad sign for temp. regulation for the board). I pressed the reset button and the board shut off (including the green light that was initially flashing).

4. What is the purpose of the wavelet generator being plugged into the trigger port? Is it acting as a clock signal?

5. And then of course, the main question is why nothing is readable from the scope.

Really appreciate your help in advance!!

[georgevigelette]

Hi Mikael,

So the inhibit signal just enable or disables the trigger so you will need to provide a logic high to the inhibit to allow the trigger to work.

On the embedded firmware the pin PC11 could be configured as GPIO output and set to high so that the trigger is always active. There is a requirement for active cooling, I have only ran this board with +12V and -12V as my high voltage and the TX7332 chips would heat-up but not go into thermal shutdown. In our lab using +/- 100V as the high voltage levels to drive a transducer, the board will go into thermal shutdown if no cooling is provided for the TX7332 chips.

For the input, the example JSON will setup the waveform for one cycle at 5MHz repeated 5 times at 1ms PRF, since it is 1KHz burst PRF the trigger should probably be slower like in the Hertz like 10Hz trigger with a 10ms pulse width. Setting the focus just will change the focus point of the sound.

[mikaelhaji]

Hi George,

Thank you for your response!

re 1. I am providing the board the 12V signal as stated and it almost immediately goes into thermal shutdown (red light immediately turns on) after downloading the json onto the board. Any thoughts on how I can provide the active cooling you stated to avoid this from happening? Is it worrisome that the board is shutting down at such a low voltage?

re 2. Regarding the inhibit signal, would I be able to just feed a active high signal into the board through my generator? ie. a DC offset waveform with a xV input into the port?

[mikaelhaji]

Update:

• Set the PC11 pin top GPIO Output & Set the inhibit signal to 10Hz with 10 ms pw

When downloading the json file, to the board, it immediately became red again and stalled at:

`C:\Users\mikae\USTX\opw_ustx\application\ustx-onda\msvc\x64\Debug>ustx-onda.exe C:\Users\mikae\Downloads\fus.json 8
Sending Hex file, estimated time: 0 seconds
__________________________________________________
##################################################
Download Successful`

Following this, I clicked the reset button and then pressed hard on my j-link (very confusing as to why this would get the job done) and that allowed for the green light to begin flashing again. This also brought the rest of the command line in:

Focus Delay: 21.2us
Set Focus:

Still unfortunately, nothing is read through the scope. Thanks for all your help once again!

[georgevigelette]

Hi Mikael,

Sorry for the late response, finally got back to this and figured I would just create a software trigger so that I didn't have to make a spot for the signal generator on my desk. I have a branch with a 50Hz trigger that can be used for a quick test. I have let it run for about an hour without any issues (no overheating and no heatsinks on my TX chips operating at +/-12v for the high voltage supply). https://github.com/OpenwaterHealth/opw_ustx/tree/internal_SW_trigger_50Hz

you should see a burst every 20ms.

[georgevigelette]

Here is a picture of my setup. the pulse is always on but a command can be added to turn it on and off or configure different frequencies.

[georgevigelette]

I also added some carriage returns to the printfs so that it is a bit easier to read

[mikaelhaji]

Hi George,

This is amazing and very much appreciated! Very excited to test this out. Quick question - I realize that my VDD+/VDD- wiring might be messed up 🤦‍♂️. Currently, I have been hooking up VDD+ to the red nozzle of my PSU and then the VDD- to the black nozzle of my PSU (refer to image below). - ultimately just setting one channel to +12V

Am I correct to assume that the reason why a 2 channel PSU is recc. is because one channel should have 12V and the other -12V and then the middle two are ground that would be connected to the black nozzles respectively.

Also, for the great implementation you have provided :) - would I just run everything as usual without the use of the inhibit port and the trigger port to make use of this software trigger?

Thank you so much for all your help!

[georgevigelette]

You will need to connect +12 and -12 rails for the system to work. Off of a 2 channel power supply if you set both channels to 12v and connect them in series you can run the center tap to ground and the use the positive terminal for +12v and the negative terminal for -12v. Like the image below

[mikaelhaji]

Hi George,

I have gone ahead and attempted to load in your branch with the software trigger, along with the changes in powering the board with the +/-12V using both channels of my PSU. Unfortunately, I am still unable to pick up on any burst on my oscilloscope. Am I supposed to assign these waves to the pinout through the executable + json file or is it simply supposed to start emitting after building the STM firmware?

Here are some pictures of my setup:

Am I supposed to do anything in Visual Studio to get this working - given the exe is already there?

Really appreciate all your help with this!

[georgevigelette]

Hi Mikael,

Try these steps:

• flash the firmware from the internal trigger branch
• test the trigger signal at the test point it should be 50hz with a 75ns pulsewidth
• runt the c++ console application with the command and using the json file attached test.json and using your com port number ustx-onda.exe test.json 12
• this should show the waveform at this point

test.json

[mikaelhaji]

Hi George,

Apologies for the back and forth. I went ahead and flashed the internal trigger branch once again on my board. I then attempted to test the trigger signal at the test point using my Oscilloscope. Unfortunately, nothing was read through this.

https://github.com/OpenwaterHealth/opw_ustx/assets/68840767/66735393-905b-449b-a745-6eaca7ad87b7

I decided to continue with the rest of the steps to get a full picture. Immediately when running this command:

ustx-onda.exe test.json 8

We got this output:

Sending Hex file, estimated time: 0 seconds
__________________________________________________
##################################################
Download Successful

and the board went into thermal shutdown:

I then had to press the reset button, press hard on my j-link and somehow the board began flashing green again - the console then also continued with this:

Focus Delay: 21.2us
Set Focus:

Throughout this entire duration, the scope picked up on nothing.

Would love your thoughts on why this is the case. This was the norm for two different boards so I don't think it is a problem with the actual pcbs.

[georgevigelette]

That is odd, I am using the same repo and the machine that I am running on hasn't ever ran this USTXv1 device, I had to set the board up and build everything from the repo to get it up and running. I have let it run and don't see the board go into thermal shutdown at all. I know it needed active cooling when we ran +/- 100V as the high voltage supply.

• Are the TX7332 chips hot to the touch?
• if the trigger isn't present you can check for the trigger at U18 pin1 or R29 this will be the pulse from the MCU which should also exist at U18 pin 4 the output of the or gate.
• check your crystal output across R2 make sure that is at 200MHz
• Ensure that your TX7332 chips have AVDDM at -5V, AVDDP at 5V, VDDIO at 2.5V, AVDDM_HV at -12V and AVDDP_HV at 12

Without the trigger pulse this will not output anything, so that does need to be present. If everything checks out, the next thing would be to determine why the trigger pulse is not making it through.

[mikaelhaji]

Hi George,

In the process of checking for the voltage, one of the TX7332 chips "bursted"/burnt out and began emitting smoke. You can somewhat see the remnants of this event in the picture below:

I am extremely confused as to why/how this occurred and am interested to hear your thoughts. We inputted +/-12V as recc. and also had a USB C and barrel jack plugged in.

Before this occurred, I validated that there was a square pulse type wave that was coming out of U18 and R29. R2 was less easier to validate but it seemed there was just an offset of sorts, assuming it was measured correctly.