I’ve tried different ‘non default’ baud rates, confirmed my serial cable was good via RaspPi test.
Suspect something odd about the clocking.
See ‘C’ returned when I press return twice. So it receives input. Just get garbage characters back like the baud rate is wrong. Tested different baud rates (as I said before) then tried different stop bits, and transmit delays (don’t see a reason to believe transmit delay would have helped since that is RX side on BP).
Ideas on RMA process - pretty sure not a config problem, did not receive an acknowledgement email for RMA process.
Bought through TI - thinking I should contact them next.
Some clarifications:
I’m seeing a character returned after pressing the CR twice. It happens it is a C.
At power up, I see garbage characters.
Since I get something response to two CRs that happens to be a ‘C’
The TX/RX lines must be correct.
I have not seen any emails regarding RMA,
I think I need to return to TI.
Well I have not returned the unit yet. But may have found some important information related to it.
Just making note here.
So on a SK_AM623BP1 EVK board, I just connected the serial cable. This is how you can determine they SoC information as well. In the UART boot mode.
The terminal dumps the SoC info and then sends C’s periodically.
And you use XModem to load files. While this does not make sense when booting from SD card where you would think the serial interface would be a basic console interface, I’m wondering now if somehow it is in some sort of XModem state.
I’ll try to follow up later, but now that I have my newer fuller featured for custom board (not end goal/hobby board) that aligns with my goals much more closely, I’m not sure when I will get back to it.
I do know I want to use it eventually to drive servos, perhaps control a telescope pointing mechanism like Auto Star- But since I’ve raised this personal challenge here - I guess I’ll just have to do it then. Even if this is some sort of baud rate issue or board issue I’d just exchange it.
It is when you are connected to the linux debug port. You need an FTDI based ttl to usb convertor connected to the debug port and use GtkTerm set at 115k, you have to grab the USB port on the linux box in gtkterm, it typically comes up USB0 or USB1 on Debian or Ubuntu. If you don’t monitor the debug port you will not know what is exactly going on.
This adapter works, we use it here. Pretty sure that is the exact model we have, if its not I will update this post.
