Failed DDOP upload with GS4 #465
Comments
|
I forgot the log output: |
|
I just came to another realization: |
|
Interesting... sending a clear to send with more frames than our request is unusual behavior on John Deere's side. And, getting an object pool transfer response so early is strange when I don't see any abort messages in the log.... Could we also ask for a can trace? That would help us quite a bit in this case. On Ubuntu, it'd be |
I uploaded the I've been trying to gather more information on potentially relate issue that is causing a failed upload. There is a irect correlation to adding these specific devices to the bus and preventing the upload from completing. My best guess right now is that they are broadcasting an address claim PGN on the bus every 5 seconds and that is causing all the nodes to reply. I end up seeing several of these from the example code: |
|
Yeah, so, looking at the CAN trace, the Deere display isn't aborting the ETP session, and is sending an incorrect transfer response, which is what's causing the issue. I also don't see any obvious protocol exceptions like timeouts, though their device is being weird by clearing us to send more packets than requested - that is certainly unusual.
This log file at least doesn't have that going on. Regardless, I would definitely say this is a Deere software issue. Their device is behaving very strangely. Going by what the CAN trace says, which has to be the source of "who is wrong" here, it is pretty clear to me that they are doing bad things. I will say, you can change those sizes you mentioned without changing the code instead! See Changing the max packet count seems like it would be an OK workaround if it helps. If you have a CAN trace of this other situation with all the address claims, I can take a look at that as well, but I'm not really sure what else to say without a contact at Deere to have them investigate their bad behavior in this case. |
|
Ok, thanks for looking into it and the tip. I will look into changing that through the I had the device that was address claiming unplugged at the time of this upload, in effort to reduce the number variables at play. I wonder if this could be is a CAN hardware/bus issue. I'll see if I can dig up some CAN logs from the JD side, at least that will at least confirm your findings. I'll be away fro the tractor for a few days, but I will see about getting another capture this week. I appreciate the help. |
|
Attached are some logs and candump of the demo working and not working when i add the ECU doing the address claiming. Any tips are greatly appreciated. Thanks again! |
|
Here are some additional crumbs, I was able to get it upload and work as expected by commenting out the following code: diff --git a/isobus/src/can_network_manager.cpp b/isobus/src/can_network_manager.cpp
index 8dc5598..257514d 100644
--- a/isobus/src/can_network_manager.cpp
+++ b/isobus/src/can_network_manager.cpp
@@ -1042,7 +1042,7 @@ namespace isobus
{
CANMessage currentMessage = get_next_can_message_from_rx_queue();
- update_address_table(currentMessage);
+ // update_address_table(currentMessage);
process_can_message_for_address_violations(currentMessage);
// Update Special Callbacks, like protocols and non-cf specific onesI don't know enough about the stack to understand why, or even what consequences I'll see by leaving that code out. But hopefully it helps understand the issue I'm facing a bit more. Thanks |
Running the TaskControl on the GS4 on main branch 2c58692e fails to complete the DDOP upload.
I was able to work around the issue by changing the following:
Environment
I've reproduced it with two Ubuntu systems, on my desktop and on a embedded ARM64 ECU.
The upload completes when attached to a TopCon controller, but not the Deere. I also messed around with the examples and can get it working if I shut off the VT upload (so only the TC DDOP).
Additional context
FailedTcDdopUpload.log
The text was updated successfully, but these errors were encountered: