sparkfun / SparkFun_Thing_Plus_MGM240P

3 stars 0 forks source link

Onboard JLink UART issue #1

Closed SiarheiVolkau closed 3 months ago

SiarheiVolkau commented 3 months ago

I'm actually have no hope that this issue will be fixed someday, just want to warn everyone that This piece of hardware can't be used for roles like NCP/RCP (Network/Radio Co-Processor) because integrated onboard JLink debugger, which also tries to act as USB-to-TTL converter, unable to do UART conversion properly.

It drops a lot of data transmitted by the MGM240 and sends a few bytes of obscure data every two seconds to MGM240 thus using any OpenThread CLI example or act as co-processor become impossible for this device, only with external debugger/USB-to-TTL converter it became feasible.

sfe-SparkFro commented 3 months ago

Hi there, sorry to hear you're having trouble!

Could you please elaborate on what exactly you're doing to test this? I tried a quick test on my end and am unable to replicate what you describe.

For reference, I'm using the 2.0.0 release of the SiLabs Arduino boards package, and I uploaded the following sketch:

void setup() {
  Serial.begin(115200);
  Serial.println("Hello world!");
}

void loop() {
  if(Serial.available())
    Serial.print((char) Serial.read());
}

sends a few bytes of obscure data every two seconds to MGM240

This is a simple serial echo sketch, which works as expected on my end. This should also detect and print any erroneous data coming from the debugger, but I've had it running for several minutes without anything unexpected happening. I've also been looking at the TX/RX pins with an oscilloscope, and the scope hasn't detected anything from the debugger.

image

The MGM240P does appear to send a couple erroneous bytes when it boots up (indicated by the 2 box symbols at the start), but that shouldn't have any effect while in operation.

Perhaps you can try doing this as well to see if your board is behaving different from mine?

It drops a lot of data transmitted by the MGM240

I haven't tested this part yet, but given that I'm unable to replicate the above, I suspect the root problem may be something else in your setup, or your board is somehow different from mine.

Hope this helps! If you're able to test what I did above, would be great to hear your results! Thanks!

SiarheiVolkau commented 3 months ago

Sure, here is my setup: ArchLinux on the host PC (Silabs udev rules installed). Simplicity Studio 5 with Gecko SDK 4.4.3 (older SDKs tried as well). Simplicity Commander, used for flashing.

The project is the example called Platform - I/O Stream USART Bare-metal with no modifications. Build it then flash via Simplicity Commander. Use UART via minicom/picocom to communicate with the example by UART: e.g. picocom -b 115200 /dev/ttyACM0 I saw ~ symbols in the output periodically and output might stop for a while.

Unfortunately for this issue, fortunately for me I can't reproduce this issue anymore, all of mine devices start working as expected. So I'm closing this issue until I can reproduce it again.

Thanks for quick response.

sfe-SparkFro commented 3 months ago

Thanks for sharing that info! If it does come up again, please follow up with replication instructions so we can try to figure out the root problem. I suspect, and I hope, that the problem is not with the J-Link chip, but would need to do more testing to actually determine that.