UART got to be kidding me

UART is a serial protocol that most embedded devices use. The previous device used UART that talked to a special USB chip (16u2 I believe) that was programmed to do essentially serial over USB by way of HID packets.

However, the HID is not necessary - one can talk to a BitLox using straight serial 57600-8-N-1. You have to talk HEX to it; that's what it understands.

So we can talk to the device - via USB built-in it seems. We'll stub this out and it WILL be functional, but we will not include USB on the final product. I'll put POGO pins on the board in case someone is determined enough that they really want USB or something.

So now I can yell at the device - why won't it respond? I can send a byte - but one a second byte is sent, total lockup. I know it CAN send a response, as I tested the spewUART() function and it appropriately spews 0xDEADBEEF.

Evidently it's as usual a stack smash.

memset(&message_buffer, 0, sizeof(message_buffer));

So after asking grok a series of questions, he suggested the following

static union MessageBufferUnion message_buffer __attribute__((aligned(4)));

Interesting.

Anyways, now I can get the device to correctly respond to raw hex command such as 2323000B000000020800 (load wallet 00) but only when using serial port hex (USB on the device) or LightBlue (BLE on the device). USB seems to get the correct replies; BLE not so much.

The real pain is that now I don't have a viable USB app to talk to the device since Chrome stomped all USB access for my app. It now claims it must be run on a Chromebook, which is a real pain here in China as I cannot access Google's services unless I set up a router-level VPN.

The BLE also seems to crap out at initialization in the app - even thought the app works with legacy devices, and I've plastered on a BrundleBLE of a module.

The module seems to work but has some odd issues like not being able to rename? Perhaps that is the root of the problem as to why it will not talk to the app properly. We have the UART BPS set to 0x05 as it should be, I think I'm going to have to check .... hey perhaps can check a module in situ then if it works pull it off the board onto a breakout. That will determine if somehow the wiring is at fault? Maybe I need pull-ups. I'd go look at the original schematics but those are pretty buried....Still, would make sense.