I try sending some value in hexadecimal like 0x0201 from DSP TMS320F28379D to JetsonNano development kit using SCI. however, when i send this data the jetson nano not receiving correctly as it shown 0x8000. i try separate the bytes into low and high and send it separately using little-endian. but the jetson nano still received wrongly.
Hi dyan.puspita1998,
Are you using the devkit or custom board for Jetson Nano?
What’s the Jetpack version in use?
Which serial interface you are using for Jetson Nano?
Could you share the block diagram of your connection?
Please also share the steps how you perform the test. (baudrate? parity? flow control?)
i use jetson nano devkit with jetpack 4.6.1.
i use UART gpio for SCI and using jumper to connect between device and oscilloscope.
baudrate: 115200
bits :8
parity:none
stopbit:1
when i run the c2000 to send for example here 0x55AA with big-endians and jetson also receive in same format. the jwtson read the data wrong. like here is 0x98E6
i dont have a photo but the received data back from jetson to dsp again also wrong like 0x00AA
its like the data i send is scramble. i though because the endians is wrong. but even with same endians for both c2000 and jetson it still show wrong value
Could you verify if there’s similar issue if you perform UART loopback test through shorting TX/RX?
Have you tried using Logic Analyzer or scope to check what’s the data been sent?
if i use loopback code for each saparate dsp and jetson nano all worked perfectly fine.
but when i try connecting SCI tx and rx for both jetson and dsp it show this.
now i dont have Logic Analyzer but if i see frome scope it show 0x55AA in the (tx of dsp or rx of jetson) and 0x00AA in the (tx of jetson or rx of dsp)
Is your device set up for a 3.3V logic level? If one side is intended for lower voltage, and the other for a higher voltage, then it is conceivable that communications in one direction might work (although it would work with an overvoltage).
Do you mean that you measure DSP send(Jetson receive) 0x55AA on signal but Jetson read 0x98E6 from your python script?
As linuxdev said, have you checked the level at both sides?
Are they both 1.8V or 3.3V?
If not, you have to use level shift to make them working on the similar level.
yes, both of them have 3.3V is there other reason that the data get shifted or swaped?
Could you try using cat command on Jetson Nano to read data sent from your DSP?
Please also let me know which UART interface you are using and share the full dmesg for further check.
Just some wild thoughts, I have seen numbering look incorrect if the binary was valid in copy, but one side interpreted as a UTF-8 character while the other side interpreted UTF-16. In other words, the display was altered even though underlying data was the same. Having an app which displays actual uninterpreted bytes though means that can’t be the issue.
I’ve also seen a UART on one side have a different byte size (should be 8-bit) or different number of stop bits (could be an issue, still it doesn’t happen very often). This essentially results in a bit shift.
The 0x55aa is used a lot, it is the “magic byte” sequence at the end of an old style BIOS MBR. However, some questions:
- Does your incorrect data always repeat exactly the same way, or does it behave like random noise?
- If you transfer all NULL bytes, 0x00 or 0x0000 (if two bytes at a time…extend this for however many bytes you are sending), what gets output?
- If you transfer all 1 bits, is there an output pattern?
Some other issue is more likely, but those are easy to test.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.