(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

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

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

Thanks for the quick replies and knowledgable insights, I appreciate you saving me going down the dead ends.

I have a dual channel scope that I am doing most of the debugging work with.

Can you tell me what the interrogation packet is thst is sent to the stm chip? I can loop it back into the native uart on the pi or a usb interface to confirm its coming out okay (assuming its a printable characters).

I think for now I can work around the programmer using the openocd utility, but in parallel I already have a physical programmer on its way, hopefully here Saturday. I know openocd did something as I started with a blank ic and now it at least has the running led pattern and then the HB signal at powerup. Not saying there is/isn't corruption in the transfer though. I am new to that utility and there is a bit of code hacking to be done with it.

I can try to get a fresh card programmed up, have plenty of quality cards to use. Should be able to do the basics tomorrow and will let you know how it comes along with the fresh card.

If you are willing, can you compile/provide a fresh hex for the stm32f446ret6 chipset to try? Im open to whatever makes sense to eliminate variables

KE7FNS
Posts: 363
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 7:04 am

KG7PAR wrote:
Thu Aug 22, 2019 5:04 am
Thanks for the quick replies and knowledgable insights, I appreciate you saving me going down the dead ends.
No problem. I do think this sort of stuff is very interesting, and there isn't anyone else on these forums engaging in this sort of discussion.
KG7PAR wrote:
Thu Aug 22, 2019 5:04 am
I have a dual channel scope that I am doing most of the debugging work with.

Can you tell me what the interrogation packet is thst is sent to the stm chip? I can loop it back into the native uart on the pi or a usb interface to confirm its coming out okay (assuming its a printable characters).
Honestly, I have never actually captured or inspected the packets going between MMDVMHost and the modem, I don't have access to that sort of sophisticated equipment, but looking at the code it should just be the following:

Code: Select all

0xE0 0x03 0x00
https://github.com/g4klx/MMDVMHost/blob ... .cpp#L1365
Heres the code where its setting up that message packet.

https://github.com/g4klx/MMDVMHost/blob ... em.cpp#L44 is the list of instructions for the lack of a better term. The first location in the packet is always MMDVM_FRAME_START. The second location is the total length of the message, and the last is the instruction.

I'm in the process of learning how to setup an inline serial debugger so I can physically watch whats going on in the STM32, but I haven't found any instructions, so I'm basically teaching myself. Right now I'm waiting on cygwin downloading a bazillion files. XD
KG7PAR wrote:
Thu Aug 22, 2019 5:04 am
I think for now I can work around the programmer using the openocd utility, but in parallel I already have a physical programmer on its way, hopefully here Saturday. I know openocd did something as I started with a blank ic and now it at least has the running led pattern and then the HB signal at powerup. Not saying there is/isn't corruption in the transfer though. I am new to that utility and there is a bit of code hacking to be done with it.
Well, I would think that if the STM32 flashing tool didn't report an error it would of been fine. I have encountered a STM32 that for some unknown reason was corrupted and needed to be reflashed with a new firmware, but I don't have any idea what caused it.
KG7PAR wrote:
Thu Aug 22, 2019 5:04 am
I can try to get a fresh card programmed up, have plenty of quality cards to use. Should be able to do the basics tomorrow and will let you know how it comes along with the fresh card.
Yeah, if it does it again, let me know and I'll show you how I detected the corruption.

KG7PAR wrote:
Thu Aug 22, 2019 5:04 am
If you are willing, can you compile/provide a fresh hex for the stm32f446ret6 chipset to try? Im open to whatever makes sense to eliminate variables
I really don't have any idea how to accomplish that. I only know how to compile and build the stuff located at https://github.com/juribeparada/MMDVM_HS

And I don't think any of those use a STM32 F4, I'm pretty sure they are all F1's, plus theres all these other settings for LED's and ADF7021's.

If we can find the code where they built that hex you listed earlier, then I'm sure I can build it, or at least help you get it built. I'll so some searching.
All views, comments, posts and opinions shared are entirely my own.

KE7FNS
Posts: 363
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 7:31 am

I've found the source code they are using here. Turns out I was wrong, they actually used the code that MMDVM_HS was forked from.

https://github.com/N4IRS/MMDVM-Install/ ... /STM32-DVM

Just follow the instructions in the README.txt, Steve N4IRS does a great job with scripting, I used to use his scripts to install asterisk on raspbian a few years ago when he was active in Allstarlink, it seems he's deleted all of that work, I wish I would of forked it before he nuked it all.

Then, if the communications are still acting up, I'll show you where to go to slow down the com port speed.
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 » Fri Aug 23, 2019 4:15 pm

I will poke on this more this weekend, but I did a fresh burn of the same pi-star download and still can't get the GUI to load even with the pristine image. I can ssh in without any issues at all, so I am suspecting it is an issue with CHROME but I haven't yet dug into it enough to fully establish that it is in fact a browser related issue.

I will keep you posted as I make more progress

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 » Fri Aug 23, 2019 4:22 pm

Scratch that last one, I decided to remote in to my home computer and try IE having thought about the browser being the culprit and I now know it is a CHROME issue. I tried using incognito mode and still won't connect, but I switched to IE and it loaded right up.

I suspect chrome is trying to load up the Open Repeater GUI or something else that is hidden in a cache/DNS somewhere which is normally at the same address and is getting confused.

Since I have the other image already configured for all the peripherals, I will switch back to it tonight and make sure it is doing the same thing with CHROME vs IE.

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

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

Post by KE7FNS » Sat Aug 24, 2019 12:19 am

How are you trying to connect to it through the browser?

I have the best luck by just typing in the IP address, and not using the hostname. I don't have bonjour support installed on this machine, so it definitely doesn't like adding the .local.
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 » Sat Aug 24, 2019 2:46 am

I just finally got it after flushing the entire DNS, and then using http://pi-star.local, the weird thing is a direct IP fails still...

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 » Sat Aug 24, 2019 6:59 pm

I finally broke out my USB to UART dongle and got it setup to sniff the output of the MMDVM UART going from the pi to the stm. The codes I am getting are

0xF0 vs 0xE0 (bit 4 error)
0x83 vs 0x03 (bit 7 error)
0x80 vs 0x00 (bit 7 error)

this looks suspiciously close to the right codes you provided, but not quite there.

I next have gotten realterm setup and send the right sequence using a USB to UART device, and I am getting the following back (as ascii characters)

ؠMMDVM 20190130 (D-Star/DMR/System Fusion/P25/NXDN/POCSAG) 12.0000 MHz GitID #ff7a9fd

Based on this I think I can conclude that the woes I am facing really all stem from having a non ideal clock source for the UART. The error rates seem to be consistent enough to break things. I am going to see if I have anything around that can generate the right frequency (like perhaps another rpi) until I can get the right crystal ordered.

AF6VN
Posts: 253
Joined: Fri Jul 20, 2018 1:15 am

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

Post by AF6VN » Sun Aug 25, 2019 6:56 pm

KG7PAR wrote:
Sat Aug 24, 2019 6:59 pm
0xF0 vs 0xE0 (bit 4 error)
0x83 vs 0x03 (bit 7 error)
0x80 vs 0x00 (bit 7 error)

this looks suspiciously close to the right codes you provided, but not quite there.
How are you counting bits? 7..0?

While I can't explain the first pair, the others almost look like something configured for 7-bit/mark parity (or 7-bit/odd parity), rather than 8-bit/no parity.

Asynchronous serial (UART) tends to be somewhat forgiving of timing mismatches, since each byte transferred is indicated with start-bit signal, so both ends will be in agreement on the start of the byte. You've then got only 8-bit times of data before stop bits (which would look like 0 bits if a receiver were still sampling the data line).

"Serial Port Complete 2nd Ed" suggests that UART clocks traditionally run 16X the (maximum) bit rate, and the link can have up to 3% clock rate error without data corruption. It also states that data is sent LSB first. Since stop bits are "0", a receiver sampling too slowly would read the stop bit as the final (MSB). A receiver sampling too fast would tend to duplicate the next-to-last bit as the MSB. Neither situation matches your data (if it were supposed to be x80 or x83 and you received x00/x03 I have no idea... as reading the stop bit for bit 7 implies bit 7 was read as bit 6, giving x40/x43; Similarly, duplicating next to last bit, for your data, again would see a 0 bit).

The use of a 16X (or higher) internal clock means the receiver can sample multiple times within a bit time and use the most common result (book says some hardware does this), normally sampling will be done at the middle of the bit time, or 8-internal clocks in (24 clocks after start bit detected, then every 16 clocks until stop bit time). A UART still seeing a 1-bit when it expects to sample a stop-bit (0) should produce a framing error in its status register.

Assuming the sender is accurate 115200bps (ignoring the 16X internal clock difference) a 3% delta means the receiver could be running 111744 to 118656 (115200 +/- 3456) before data corruption is noticed.

--
AF6VN
Dennis L Bieber

KE7FNS
Posts: 363
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 26, 2019 1:55 am

KG7PAR wrote:
Sat Aug 24, 2019 6:59 pm
0xF0 vs 0xE0 (bit 4 error)
0x83 vs 0x03 (bit 7 error)
0x80 vs 0x00 (bit 7 error)
Thats really crazy that you are getting bit errors like that, I'm not sure what could be causing that. Is this coming right off the UART board and into the USB->UART adapter?

I2C shouldn't have any problems going that slow, I know on drone flight controllers that use STM32's, they are running i2c at 800kHz.

You have GPIO 24 (pin 18) connected to both the UART board and the RPi for IRQ right?

Also, while poking around I read a post somewhere that said they were getting errors when both serial ports were in use simultaneously. Can you try with the second serial port unused?

Are you using a board that was preassembled or are you building a new circuit with that specific chip??
All views, comments, posts and opinions shared are entirely my own.

Post Reply