I'm using MPLab Harmony to program a custom board based on ATSAME51J20A microprocessor from microchip.
I didn't find any Arduino library that would enable me to use the two CAN bus available on this chip, so I started looking into MPLab.
I've used the code generator that created me functions to use CAN0 and CAN1.
The problem comes when I try to send CAN messages:
The initialization works well. Then I call "CAN1_MessageTransmitFifo(...)" which returns true (no error) but no message arrives at the other end point.
The only error I can get is when I debug the program and look at the data returned by CAN1_ErrorGet(), it returns 0x707 which seems to be the bits indicating "CAN_PSR_LEC_NC_Val: (CAN_PSR) No Change" and I have no clue what it means.
Note that I was able to successfully use the CAN1 by using the adafruit library CAN.h. So on this bus we can reject the possibility of a hardware problem.
Below you will find screenshots of my configuration:
The project graph
Pin diagram
In the configuration options section I also get these weird warnings (for CAN0 and CAN1). I've highlighted them.
Configuration options
Here is the code sending the CAN message (after initialization):
CAN_TX_BUFFER msg = {0};
msg.id = 0xAB;
msg.data[0] = 'H';
CAN1_MessageTransmitFifo(1, &msg);
I'm sure I'm sending and receiving at the same speed (500KB/s) and on the logic analyser I only get garbage on the CAN lines (lots of random spikes).
Am I missing something ?
If you have a solution that doesn't use MPLab but permits the use of the two CAN bus and the two I2C I'm very interested.
And if you know what could cause the issue, please let me know.
Thank you in advance.
Related
For the past few weeks, i have been trying to make a HTTP request on a SIMCOM7080. I'm controlling this module via AT Commands. Every path that i try, ends with an ERROR. Does anyone have experience on getting this module to talk with for example Thingspeak? The link that i have tried is this one:
https://prod-162.westeurope.logic.azure.com/workflows/48fcd3ff69634babaa31ef51f89e2051/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=_4eWTUWPLqk5evTp1014kcntXff4akjlFpQJZo_5dFc
The purpose for this is to eventually connect this to an arduino via a UART connection, and displaying data on an IoT device.
Thanks in advance!
Every path with AT commands ends in an error. I have looked up all the documentation given by the manufacturer but it ends with ERROR.
I'm able to build and use the Bluez\tools\btgatt_client.c code to send <20 bytes with the write-value command, but can't get the write-long-value or write-prepare/write-execute commands to work. It fails at the bt_gatt_client_write_long_value() function.
I've already developed client code for our system using the Bluez dbus interface including OTA/DFU capability, but it has many issues. So my goal is to use these Bluez\src\shared\gatt-client.c functions directly in my client app. Plus, I could be wrong but I've traced the function call chain through the dbus interface, back to these atomic functions. And even though many suggest we really should be using the dbus API, I've greatly improved the scanning/discovery part of my code without it. And like I said, I'm able to send data with the bt_gatt_client_write_value() function.
So what's the difference between bt_gatt_client_write_long_value() and
bt_gatt_client_prepare_write()/bt_gatt_client_write_execute().
I've tried changing the MTU, watching traffic with btmon...
Not sure why they work through the dbus API but not through the btgatt-client tool. Gotta be how I'm setting up the function parameter structs???
Maybe these are not the low level functions to use.
I appreciate any and all help, thanks.
More info...
I'm still trying to understand why the btgatt-client tool won't work when I write more than 20 bytes even with large MTU settings, at 247. I see the tool uses the same atomic functions as does the dbus API proxy WriteValue call. I've traced the function call chain: WriteValue ->
Bluez\src\gatt-client.c\characteristic_write_value() ->
Bluez\src\gatt-client.c\start_write_request() ->
Bluez\src\shared\gatt-client.c\bt_gatt_client_write_value() for less than MTU-3 value sizes.
For value sizes > MTU-3, I think it uses the Prepare Writes and Execute Write functions?
Comparing btmon output from my existing dbus code and the btgatt-client tool, writing the same string of just 21 bytes: "k 1234567890 3200 512", shows both sending the same Write Request (0x12). All the connection parameters seem to be the same for both.
But I do see a difference in the response: 2 packets for working code, but only 1 for the tool:
HCI Event: Number of Completed Packets (0x13) plen 5 #738 [hci0] 1081.642076
Num handles: 1
Handle: 64
Count: 1
It just hangs here without send any data to the device.
I'm missing something basic??? Thanks.
I am trying to control 5V 4-Ch Relay Module http://www.icstation.com/icstation-micro-channel-relay-module-control-relay-module-icse012a-p-4012.html using Raspberry Pi-4, Model-B, 2GB RAM.
But sometimes I am observing "pl2303 ttyUSB0: pl2303_read_int_callback - usb_submit_urb failed with result -1" error and the Relay did not perform the required operation.
It would be good to know the root cause or the reason for this issue from the professional present here on this forum.
Any hint/clue would be really helpful and appreciated :) .
Thanks Again.
TL;DR: there seem to be a defect in pl2303 driver caused by race or incorrect state after multiple connect/disconnect. Simply reload the pl2303 kernel model to workaround this issue when you get it.
Error '-1' (EPERM) in kernel USB stack is rare: I can find only one occurrence in urb submit path e.g.:
https://elixir.bootlin.com/linux/v5.4.99/source/drivers/usb/core/hcd.c#L1152
More to this, kernel documentation on usb_kill_urb says:
To cancel an URB synchronously, call usb_kill_urb():
void usb_kill_urb(struct urb *urb)
It does everything usb_unlink_urb() does, and in addition it waits until after
the URB has been returned and the completion handler has finished. It also marks
the URB as temporarily unusable, so that if the completion handler or anyone
else tries to resubmit it they will get a -EPERM error
So basically driver tries to submit INT IN URB after it got killed. Looking at the pl2303 driver code you can see only 2 places where INT IN URB is poisoned, e.g.:
https://elixir.bootlin.com/linux/v5.4.65/source/drivers/usb/serial/pl2303.c#L756
https://elixir.bootlin.com/linux/v5.4.65/source/drivers/usb/serial/pl2303.c#L788
In both cases this happen on either close() or unsuccessful open() of USB serial device.
Proper fix would be to:
Check whether its open that fails on usb_serial_generic_open() function
Check whether INT IN URB killing is done properly and there's no race
Check if pl2303 code is aligned in general with recent USB Serial driver logic
Quick fix on the running system would be just
rmmod pl2303 && modprobe pl2303
I'm working on the firmware of a device that is going to be connected to PCs using Bluetooth in serial port emulation mode.
During testing, I found out that modem-manager on Linux "helpfully" tries to detect it as a modem, sending the AT+GCAP command; to this, currently my device replies with something like INVALIDCMD AT+GCAP. That is the correct response for my protocol, but obviously isn't an AT reply, so modem-manager isn't satisfied and tries again with AT+GCAP and other modem-related stuff.
Now, I found some workarounds for modem-manager (see here and thus here, in particular the udev rule method), but:
they are not extremely robust (I have to make a custom udev rule that may break if we change the Bluetooth module);
I fear that not only modem-manager, but similar software/OS features (e.g. on Windows or OS X) may give me similar annoyances.
Also, having full control over the firmware, I can add a special case for AT+GCAP and similar stuff; so, coming to my question:
Is there a standard/safe reply to AT+GCAP and other similar modem-probing queries to tell "I'm not a modem, go away and leave me alone?"
(making an answer out of the comments)
In order to indicate I do not understand any AT commands at all (aka I am not a modem) the correct response to any received AT commands should be silence.
In order to indicate I do not understand this particular AT command the correct response should be ERROR.
Anything between will trigger implementation defined behaviour of the entity sending AT commands. Some will possibly give up right away while modem-manager apparently is set on retrying sending the command until it gets a "proper" response.
I have an embedded linux project where I want to use multi-touch with Qt.
I've been looking at qTUIO ( https://github.com/x29a/qTUIO ) and it looks great.
I cross-compiled the qTUIO library and deployed to the board.
I also cross-compiled and deployed the requirements for the TUIO 'server':
http://bitmath.org/code/mtdev/
http://liblo.sourceforge.net/
http://repo.or.cz/w/mtdev2tuio.git
On the board I fired up the 'server':
./mtdev2tuio /dev/input/touchscreen osc.udp://127.0.0.1:3333/
Sending OSC/TUIO packets to osc.udp://127.0.0.1:3333/
Just to make sure that it was reading the input device I also did the following and saw the 'failure in name resolution' when I moved my finger on the touchscreen:
./mtdev2tuio /dev/input/touchscreen osc.udp://localhost:3333/
Sending OSC/TUIO packets to osc.udp://localhost:3333/
...
OSC error -3: Temporary failure in name resolution
OSC error -3: Temporary failure in name resolution
OSC error -3: Temporary failure in name resolution
OSC error -3: Temporary failure in name resolution
OSC error -3: Temporary failure in name resolution
...
I then ran the qTUIO version of the 'pinchzoom' example on the board and it is running like below with this output:
# ./pinchzoom -qws
graphicsview initialized
listening to TUIO messages on UDP port 3333
So I have a server claiming to be interpreting my touches and sending them UDP to port 3333, and the qt application claiming to be reading those TUIO events and passing them to Qt. When I touch the screen nothing happens. Does anybody have ideas on this?
can you actually fire up a network logger (like tcpdump, Wireshark) and see, if OSC packets actually get sent from your server?
The error
OSC error -3: Temporary failure in name resolution
looks like an issue on your server side, so to eliminate the client as an error source, choose a serve (tracker) different then yours. http://tuio.org/?software features a good overview, if you happen to have an Android Fon around, try http://code.google.com/p/tuiodroid/ to simulate OSC packets.
Now to the client. qTUIO is actually far from done, so there is a good chance, that it is the culprit. A good way to test, if packets are received and forwarded correctly is to look at the overloaded event() method in your code, and see, if it triggers and if yes, with which type. I can only tell you, that it worked okay with a CCV 1.4 as tracker. Also, use the paint example if possible, as it practically translates the touchevents to paintevents, less magic that could go wrong.
Working in an embedded field just adds another special flavour to error sources. Do you maybe have endianess problems? Timing issues?
Can you provide more info on which versions of libs, OS, hardware, etc. you are using?
I will gladly update this post to provide a real solution, once its clear, what component causes the error. Good luck!