(RPI) Changing the tty to an external device and validating functionality

General support for the Pi-Star System
KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

(RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Mon Aug 19, 2019 5:59 pm

Greetings Gurus,

I have designed up my own board to integrate several pieces of hardware, and I am wanting to leave the native UARTs on the rpi available for other expansions, hats, etc. In this train of thought, I elected to add in an I2C to dual uart (SC16IS752) which is shared with my GPS unit. The external UART is loaded up in the device tree successfully and reports as ttySC0 on the connection to the STM32F446 processor chip.

I *think* I have successfully programmed the microcontroller last night using openocd. Not sure yet how to confirm that is accurate or not, perhaps this will need to be the first task, but not sure how to do that since I cannot talk to the microcontroller using the GUI. The openocd reported success, but I have learned to not always trust success reports

So to start out, my first question is how do I include the ttySC0 as the communication uart between the PI and the microcontroller?

The specific area <I think> I need to change is highlighted below.
I: 2019-08-19 01:29:03.736 This software is for use on amateur radio networks only,
I: 2019-08-19 01:29:03.737 it is to be used for educational purposes only. Its use on
I: 2019-08-19 01:29:03.737 commercial networks is strictly prohibited.
I: 2019-08-19 01:29:03.737 Copyright(C) 2015-2018 by Jonathan Naylor, G4KLX and others
M: 2019-08-19 01:29:03.737 MMDVMHost-20181107_Pi-Star is starting
M: 2019-08-19 01:29:03.737 Built 09:24:10 Nov 12 2018 (GitID #9444eca)
I: 2019-08-19 01:29:03.737 General Parameters
I: 2019-08-19 01:29:03.737 Callsign: KG7PAR
I: 2019-08-19 01:29:03.737 Id: 1234567
I: 2019-08-19 01:29:03.737 Duplex: yes
I: 2019-08-19 01:29:03.737 Timeout: 240s
I: 2019-08-19 01:29:03.737 D-Star: disabled
I: 2019-08-19 01:29:03.737 DMR: disabled
I: 2019-08-19 01:29:03.737 YSF: disabled
I: 2019-08-19 01:29:03.737 P25: disabled
I: 2019-08-19 01:29:03.737 NXDN: disabled
I: 2019-08-19 01:29:03.737 POCSAG: disabled
I: 2019-08-19 01:29:03.737 Modem Parameters
I: 2019-08-19 01:29:03.737 Port: /dev/ttyAMA0
I: 2019-08-19 01:29:03.737 Protocol: uart
I: 2019-08-19 01:29:03.737 RX Invert: no
I: 2019-08-19 01:29:03.737 TX Invert: yes
I: 2019-08-19 01:29:03.737 PTT Invert: no
I: 2019-08-19 01:29:03.737 TX Delay: 100ms
I: 2019-08-19 01:29:03.737 RX Offset: 0Hz
I: 2019-08-19 01:29:03.737 TX Offset: 0Hz
I: 2019-08-19 01:29:03.737 RX DC Offset: 0
I: 2019-08-19 01:29:03.737 TX DC Offset: 0
I: 2019-08-19 01:29:03.737 RF Level: 100.0%
I: 2019-08-19 01:29:03.738 DMR Delay: 0 (0.0ms)
I: 2019-08-19 01:29:03.738 RX Level: 50.0%
I: 2019-08-19 01:29:03.738 CW Id TX Level: 50.0%
I: 2019-08-19 01:29:03.738 D-Star TX Level: 50.0%
I: 2019-08-19 01:29:03.738 DMR TX Level: 50.0%
I: 2019-08-19 01:29:03.738 YSF TX Level: 50.0%
I: 2019-08-19 01:29:03.738 P25 TX Level: 50.0%
I: 2019-08-19 01:29:03.738 NXDN TX Level: 50.0%
I: 2019-08-19 01:29:03.738 POCSAG TX Level: 50.0%
I: 2019-08-19 01:29:03.738 RX Frequency: 145999999Hz (145999999Hz)
I: 2019-08-19 01:29:03.738 TX Frequency: 146000000Hz (146000000Hz)
M: 2019-08-19 01:29:03.738 Opening the MMDVM
E: 2019-08-19 01:29:16.554 Unable to read the firmware version after six attempts
If my assumptions are way off base, please feel free to correct me and get me pointed in the right direction.

My schematic is a derivative of the Repeater Builder Version 3 board with regards to the STM32F446 circuitry.

KE7FNS
Posts: 416
Joined: Wed Apr 17, 2019 11:11 pm

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KE7FNS » Mon Aug 19, 2019 10:09 pm

I really don't understand what you are trying to do, but if you installed an i2c device, and that connects to your modem now, then you need to tell MMDVMHost that it needs to connect to an i2c device not a serial device.

Code: Select all

rpi-rw
sudo nano /etc/mmdvmhost
Set the following

Code: Select all

[Modem]
Protocol=i2c
Address=0x22
port is no longer valid when the protocol is set to i2c
if theres a # in front of Address=0x22 remove it, or add that entire line if its missing.

The address is going to be the hex address of the i2c board you installed. Sometimes they have jumpers to bridge on the board to set it.
You should be able to run this to find all the i2c devices detected.

Code: Select all

sudo i2cdetect -y 1
If you have an older RPi you need to change the -y 1 to -y 0.

I'm not sure how your board is going to convert an i2c to one or the other uart, but maybe theres 2 i2c addresses and each address goes to the specific uart or something. I'm not familiar with that specific board, but I have played around with some i2c things like OLED screens and RTC's.
All views, comments, posts and opinions shared are entirely my own.

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Tue Aug 20, 2019 12:28 am

I think I over explained it.

The pi talks i2c to the chip I have added. This part is all good, the I2c device driver loads properly and creates 2 new uart devices in the system, specifically /dev/ttySC0 and /dev/ttySC1. Again this part is fully tested and working.

I now need the mmdvm software to use the new uart at /dev/ttySC0 instead of the /dev/ttyAMA0 device for communications.

I will have a look at the /etc/mmdvmhost file tonight if I dont hear back again before then

KE7FNS
Posts: 416
Joined: Wed Apr 17, 2019 11:11 pm

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KE7FNS » Tue Aug 20, 2019 7:58 am

KG7PAR wrote:
Tue Aug 20, 2019 12:28 am
The pi talks i2c to the chip I have added. This part is all good, the I2c device driver loads properly and creates 2 new uart devices in the system, specifically /dev/ttySC0 and /dev/ttySC1. Again this part is fully tested and working.
Weird. Apparently pistar 4.1 has that overlay installed by default, cause my 3B+ lists those serial ports too.

Code: Select all

[email protected](ro):~$ ls -l /dev/ttyS*
crw-rw---- 1 root dialout   4, 64 Aug 19 13:20 /dev/ttyS0
crw-rw---- 1 root dialout 241,  0 Aug 19 13:20 /dev/ttySC0
crw-rw---- 1 root dialout 241,  1 Aug 19 13:20 /dev/ttySC1
KG7PAR wrote:
Tue Aug 20, 2019 12:28 am
I now need the mmdvm software to use the new uart at /dev/ttySC0 instead of the /dev/ttyAMA0 device for communications.
if thats the correct serial port which I'm not entirely convinced it is, then just replace every instance of /dev/ttyAMA0 with it in your mmdvmhost configuration file and restart the mmdvmhost service, or reboot.
All views, comments, posts and opinions shared are entirely my own.

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Tue Aug 20, 2019 2:11 pm

Hmm, it definitely is the right driver for my hardware as I am talking to my gps unit through it on port ttySC1. Thry disappear when i remove the overlay. Perhaps the SCx is assigned for any expansion uarts? Not sure why the 3B+ would enumerate that way otherwise, or what chip would be doing it that is unique to the 3b+. I will have to dig my 3b+ out, I am on a 3b at the moment.

I made the change to the config and probed the pins of the serial port and I dont see any traffic at all going either direction. Is there some type of regular status message or such that I should be seeing? I am now sure the stm32 is programmed as I get a led light sequence at power up and then the heart beat led toggles.

I am pretty sure its just down to figuring out why I am not getting any communications and this should all start working.

KE7FNS
Posts: 416
Joined: Wed Apr 17, 2019 11:11 pm

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KE7FNS » Tue Aug 20, 2019 9:16 pm

KG7PAR wrote:
Tue Aug 20, 2019 2:11 pm
Hmm, it definitely is the right driver for my hardware as I am talking to my gps unit through it on port ttySC1. Thry disappear when i remove the overlay. Perhaps the SCx is assigned for any expansion uarts? Not sure why the 3B+ would enumerate that way otherwise, or what chip would be doing it that is unique to the 3b+. I will have to dig my 3b+ out, I am on a 3b at the moment.
It seems pistar 4.1 loads that overlay by default now. I have no idea why or if the serial ports listed even work or not. I certainly don't have an expansion board installed.
KG7PAR wrote:
Tue Aug 20, 2019 2:11 pm
I made the change to the config and probed the pins of the serial port and I dont see any traffic at all going either direction. Is there some type of regular status message or such that I should be seeing? I am now sure the stm32 is programmed as I get a led light sequence at power up and then the heart beat led toggles.
Not unless MMDVMHost detects the modem is there any steady traffic. It tries a number of times on startup to query the modem and if the modem doesn't respond it just halts, until the service is restarted.
KG7PAR wrote:
Tue Aug 20, 2019 2:11 pm
I am pretty sure its just down to figuring out why I am not getting any communications and this should all start working.
I'd start looking into how that overlay driver sets up the serial port in question, and see if theres a way to reconfigure it. It needs to be 81N 115200 baud and no flow control, that is what the STM32 is looking for.
All views, comments, posts and opinions shared are entirely my own.

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Tue Aug 20, 2019 10:37 pm

I can use typical serial tools/commands to setup the port so that part should be simple enough, I think its 9600 8n1 by default. I may have an issue with the 115200 due to clock selection (higher than ideal error rates), but that will be addressed in the next version of the board.

Is there a way to poke a register to change the baud rate by chance until I can fix the clock source?

I will get some probes and or logic analyzer probes attached to the uart pins to watch during the entire boot process. I will report back with what I can come up with for data traffic.

KE7FNS
Posts: 416
Joined: Wed Apr 17, 2019 11:11 pm

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KE7FNS » Wed Aug 21, 2019 4:27 am

KG7PAR wrote:
Tue Aug 20, 2019 10:37 pm
I can use typical serial tools/commands to setup the port so that part should be simple enough, I think its 9600 8n1 by default. I may have an issue with the 115200 due to clock selection (higher than ideal error rates), but that will be addressed in the next version of the board.

Is there a way to poke a register to change the baud rate by chance until I can fix the clock source?

I will get some probes and or logic analyzer probes attached to the uart pins to watch during the entire boot process. I will report back with what I can come up with for data traffic.
Nope, you haven't really elaborated on which firmware you have loaded in the STM32, but I assume you are loading the most popular one. Either way, I'm sure its forked from it at least.

https://github.com/juribeparada/MMDVM_H ... t.cpp#L545

That line right there specifies the UART 1 speed (when I say UART 1, I mean 1 of the 2 that are physically on the STM32), and the speed is determined by that value, so if you can't get your serial port up to that speed without errors, then you'll have to build a custom firmware and set it to be lower baudrate. MMDVMHost will just follow along. You are also going to have to manually go in and change the serial port in the makefile to point to that new serial port for flashing, or what I'd do in your case is use another stock RPi with pi-star to build and flash the modem, and then manually move the modem over to your testing station.

i2c shouldn't have an issue with that speed, it can go way faster. I've talked to a STM32 over serial without errors at speeds much higher than 115200 also, I'm talking about speeds in Mbps.

I'd bet that your issue is a port speed mismatch. If you can look at if that overlay has any parameters that you can set when it is loaded to set the speed, and 81N you'd have success.
All views, comments, posts and opinions shared are entirely my own.

KG7PAR
Posts: 24
Joined: Mon Aug 19, 2019 3:20 am

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KG7PAR » Thu Aug 22, 2019 3:04 am

Working on the board tonight I think I have made a few discoveries that will lead me forward.

for reference, I am using a design derivative of this one, version 3

http://repeater-builder.com/products/stm32-dvm.html

1, per this document, http://www.repeater-builder.com/product ... Hat_v3.pdf, which is the reference design and actual firmware I am using, the UART should be at 57600 which works out as a slightly better uart speed for my current design with a lower error rate (about half as high), but alas is not the default for pi-star

2) I found a reference for debuging online (https://amateurradionotes.com/pi-star-t ... ooting.htm) that failure to boot should look to pins 38 and 40 to start, these are "boot" and "nRST" respectively best I can tell. This didnt work for me as those are both reserved I2S audio pins for using I2S sound chips which I am using. As such, I moved those pins to physical pin16 for the nRST and 36 for boot.

3) from my probing the tx/rx I do see tx (from the pi) send a burst at 115200 on occasion, but never an RX, I am assuming this is a byproduct of #2 for now, but I can now confirm the uart is working in general


From what I have found tonight, I think I need to make 3 changes to the pi-star side of the configuration to match these settings.
1) uart speed as 57600
2) reset pin as physical pin 16
3) nRST pin as physical pin 36.

also, not sure what I did but the GUI seems to have died on me, wont load up on either the lan or wifi page

the mmdvmhost service as well as the nginx service are both running okay

KE7FNS
Posts: 416
Joined: Wed Apr 17, 2019 11:11 pm

Re: (RPI) Changing the tty to an external device and validating functionality

Post by KE7FNS » Thu Aug 22, 2019 4:16 am

KG7PAR wrote:
Thu Aug 22, 2019 3:04 am
1, per this document, http://www.repeater-builder.com/product ... Hat_v3.pdf, which is the reference design and actual firmware I am using, the UART should be at 57600 which works out as a slightly better uart speed for my current design with a lower error rate (about half as high), but alas is not the default for pi-star
Sorry, but that speed isn't what you think it is. That is just the default speed and port settings of the STM32 flashing tool itself. NOTE Its also even parity too.

Code: Select all

stm32flash 0.5

http://stm32flash.sourceforge.net/

ERROR: Device not specified
Usage: stm32flash [-bvngfhc] [-[rw] filename] [tty_device | i2c_device]
        -a bus_address  Bus address (e.g. for I2C port)
        -b rate         Baud rate (default 57600)
        -m mode         Serial port mode (default 8e1)


I looked over all of the links provided and that website and I can't seem to find a link to their source code of the firmware they are loading on the STM32. If you need to change the port speed you are going to have to have a copy of that to do it.

I guess if you are able to successfully flash the modem using the port you specified earlier, then start testing it at higher speeds and see if the flash takes. If the flashing tool can go that high then you don't have anything to worry about speed wise. I always flash mine at 115200.

Code: Select all

stm32flash -b 115200 -v -w mmdvm_f4.hex -i 20,-21,21,-20 -R /dev/ttySC0 
KG7PAR wrote:
Thu Aug 22, 2019 3:04 am
2) I found a reference for debuging online (https://amateurradionotes.com/pi-star-t ... ooting.htm) that failure to boot should look to pins 38 and 40 to start, these are "boot" and "nRST" respectively best I can tell. This didnt work for me as those are both reserved I2S audio pins for using I2S sound chips which I am using. As such, I moved those pins to physical pin16 for the nRST and 36 for boot.
Those pins are not required for operation, only for flashing. You can get the same results if you short out the BOOT0 pin manually before you hit enter after typing that flashing command above. Someone just figured out that you could tell the STM32 flashing tool to toggle those GPIO pins 20 and 21, and connect those GPIO pins to the STM32 and you wouldn't have to manually bridge things anymore. Some of the older MMDVM_HS boards still require manual bridging.
KG7PAR wrote:
Thu Aug 22, 2019 3:04 am
3) from my probing the tx/rx I do see tx (from the pi) send a burst at 115200 on occasion, but never an RX, I am assuming this is a byproduct of #2 for now, but I can now confirm the uart is working in general
I guess if you are getting a serial burst at 115200, but no response that would indicate to me that the STM32 isn't flashed or booting properly. It should respond when queried. Can you capture that serial data?? It sounds as if you've got access to some high powered equipment.
KG7PAR wrote:
Thu Aug 22, 2019 3:04 am
From what I have found tonight, I think I need to make 3 changes to the pi-star side of the configuration to match these settings.
1) uart speed as 57600
2) reset pin as physical pin 16
3) nRST pin as physical pin 36.

also, not sure what I did but the GUI seems to have died on me, wont load up on either the lan or wifi page

the mmdvmhost service as well as the nginx service are both running okay
You need to find the source code for the firmware, or ask whoever is providing you the .hex file you are trying to load what they set the serial port speed to. If they say they didn't change it, it is 115200 baud 81N. Like I said earlier the serial port speed is determined by the MMDVM firmware loaded on the STM32, not MMDVMHost and pi-star.

Not sure what SD card size or brand you are using, but I ran into issues with corruption using a 32 Gig Patriot SD card. That might be the cause of the webpage not loading. But no idea why it would of all the sudden quit working other than that. If you want to know how I detected the SD card corruption just ask.
All views, comments, posts and opinions shared are entirely my own.

Post Reply