Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checksum in 128B mode (Xmodem first protocol) #5

Open
ddejean opened this issue Jun 4, 2023 · 5 comments
Open

Checksum in 128B mode (Xmodem first protocol) #5

ddejean opened this issue Jun 4, 2023 · 5 comments

Comments

@ddejean
Copy link

ddejean commented Jun 4, 2023

Hi Andre,

Thanks for this very nice little library. It's very easy to use and integrate in some custom code.

I'm trying to use the library in 128B mode and I'm wondering if the following line is correct for this case :

crc = xmodem_server_crc(crc, xdm->packet_data[i]);

As far as I understand the original Xmodem protocol (the one with 128B packets) the "checksum" is a sum of the data bytes in the packet, not a CRC (as in Modem-1k). Am I missing something ?

Best regards,
Damien

@AndreRenaud
Copy link
Owner

Hi Damien,
It looks as if you're probably right. What is implemented is technically XMODEM-CRC, which uses a 16-bit CRC, not the original 8-bit checksum. I never noticed, since it looks like the command line tools I was working with (sz) operate just fine with this.

Is this causing you grief? I'd welcome a patch to make it optional?

Regards,
Andre

@ddejean
Copy link
Author

ddejean commented Jun 4, 2023

I'm currently integrating this to a 16 bit firmware and it's not working. But I don't know yet if this is the root cause, or if my modifications are causing this. I just found this while investigating :)

Anyway I'll be happy to open a pull request if that's really an issue!

Damien

@AndreRenaud
Copy link
Owner

Are you using a PC as the client, or is this between two embedded systems? I've used this as the server on an embedded when doing firmware upgrades on other embedded devices, and not had grief.

I had a poke around, and it turns out it seems to be related to the special character that is sent out on startup. If the server sends out 'C', then it's assuming xmodem-crc. If it sends out 'NACK', then it's the original 8-bit checksum.

See https://github.com/UweOhse/lrzsz/blob/master/src/lsz.c#L994 & https://github.com/UweOhse/lrzsz/blob/master/src/lrz.c#L641

I've created a branch which adds a new parameter to enable this mode of operation. You need to tell the server which mode it should start in. Have a look here and see if it makes things any better?

#6

@ddejean
Copy link
Author

ddejean commented Jun 5, 2023

Are you using a PC as the client, or is this between two embedded systems?

I'm using a PC as client to upload a firmware to an embedded system. Eventually I'd like to be able to upload a new firmware to my board from a PC, and perform an upgrade.

I had a poke around, and it turns out it seems to be related to the special character that is sent out on startup. If the server sends out 'C', then it's assuming xmodem-crc. If it sends out 'NACK', then it's the original 8-bit checksum.

That's an interesting lead, let have a look at this and come back to you. Thanks for the new branch, it will be helpful!

@AndreRenaud
Copy link
Owner

If you're using a PC, I suspect this probably isn't the issue. Most PC-based software is going to support both modes of operation and should seamlessly swap between them as appropriate. Not 100% sure obviously :)

Let me know how it goes and if there's any else I can help with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants