I have an FX30 running Octave and have it talking to some equipment via the serial port (rear port on FX30) using UART1.
It seems that every time I reboot the device the serial parser stops functioning. I know the device is still sending commands as I can plug it into the serial port on my PC and see the commands being sent.
The only way(s) I’ve found to get it working again is to either delete the usp instance (see attached pic) reboot, and then recreate the usp … or, by following the instructions here and deleting the config files.
This seems to make it start working again. It will carry on working then until the device is restarted.
I actually started working on this some time so my memory is a little fuzzy but I am pretty sure that a) it worked fine before b) I updated the firmware and its since then I have had the issue.
It has been a while ago, but I had a test running successfully for a good while using USP successfully getting data from a device using FX30S serial port. This was using 3.3.1. I don’t recall encountering this issue.
HI @dpinc , thanks for taking a look. Definitely something odd going on (or I’m missing something).
Theres a bit more going on overall, but basically, I have a piece of kit that thinks its talking to a modem with AT commands down a serial port (9600/8/N/1).
I’ve set the USP to bytes and delimited on crlf (13 10) with 5 sec timeout. I then have an observation on the /usp/my_usp resource that runs an edge action.
I’ve stripped the edge action back so all it does is write to the console to basically say “yep I’ve seen something on the serial port”.
If i delete the USP and then re-add it (Ive since found I dont need to reboot) then check the console log in the edge action, I can see the commands being read.
If I restart the FX30 and check the console in the edge action (I’ve even left it for 30+ minutes to see if it starts) then nothing comes through. If i check the usp resource its empty i.e. its not reading anything from the serial port.
If I delete the usp and then recreate it, give it 30 seconds and the messages start appearing in the console for the edge action again and the usp resource starts to show byte data.
This is FW3.4.1 I think it was on 3.3.1 before I updated it and it was working fine then.
Disconnected the hardware that the FX30 was attached to and plugged into my PC over serial. Used some software to send “hello world” up the serial connection.
This worked fine and could see the message displayed in the action log on Octave.
Restarted the FX30 and it stopped working.
Delete the USP and set up again and starts to work again.
Further update … I have another FX30 running FW3.3.1. I’ve applied the blueprint from the other device running 3.4.1 and it works fine on this one running 3.3.1.
Hi @robfaulkner
Thanks for the information regarding 3.4.1.
That’s interesting. I was running pretty much the identical scenario using AT commands to capture voltage and temp measurements periodically. I have been sticking with 3.3.1 for this and other long running tests. But will need to upgrade before too long. Thanks for confirming the issue with 3.4.1 as my tests will depend on this functionality.
No problem, if it saves someone else chasing their tail for a day then at least my frustration hasn’t been in vane No, not had any input from Sierra yet.
Further update, I noticed this morning that FW3.5.0 now available for the FX30 … I updated my device but still getting the same issue.
Further update. I’ve just installed FW3.5.1 and still having the issue. As a further check I have installed the latest blueprint to the old unit again running FW3.3.1 and as before, it works just fine.
Would really appreciate some input from @Octave on this.
Hi @robfaulkner
Sorry for the inconvenience.
We are not aware of such kind of issue with USP.
Can you send me in private your company name and device name so I have a look at the Blueprint?
Thanks
Nicolas
Hi @robfaulkner
I have found the issue.
The problem is that in the Blueprint are set both /io/config and /io/serial/config.
In /io/config resource is a JSON that contains both the serial and the GPIOs config.
Setting a value to /io/serial/config conflicts then with this setting.
And as /io/serial/config is set to an empty JSON object, it removes the UART configuration.
Solution
Let /io/serial/config (and /io/gpio/config) unchecked, that is without value set
The UART will then be configured properly everytime.
Regards,
Nicolas
Any idea why this would not have affected the unit running FW3.3.1. I have just checked and it also has the two items checked, yet it works fine on that unit still?
No, not had any input from Sierra yet.
