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

SPIcheckStream in Module.cpp is ineffective (does nothing) #1048

Closed
tve opened this issue Apr 2, 2024 · 1 comment · Fixed by #1057
Closed

SPIcheckStream in Module.cpp is ineffective (does nothing) #1048

tve opened this issue Apr 2, 2024 · 1 comment · Fixed by #1057
Assignees
Labels
bug Something isn't working resolved Issue was resolved (e.g. bug fixed, or feature implemented)

Comments

@tve
Copy link

tve commented Apr 2, 2024

Describe the bug
Module::SPIcheckStream is intended to verify the status of a command after it completes. It runs an SPIstatusCommand. However, it calls SPItransferStream with numBytes=0 which means that nothing is returned by SPItransferStream. Setting numBytes=1 fixes the issue (at least for sx1262).

Specifically, here is the call to SPItransferStream:

state = this->SPItransferStream(&cmd, 1, false, NULL, &spiStatus, 0, true, RADIOLIB_MODULE_SPI_TIMEOUT);

And here is where data received from the device is copied into the caller-provided buffer, note that it doesn't so anything if numBytes=0:
memcpy(dataIn, &buffIn[cmdLen + 1], numBytes);

To reproduce, turn on SPI debugging and observe that on an sx1262 device the normal success status for most commands is 0xA2. Add a printf to SPICheckStream to print spiStatus after the call to SPItransferStream and observe that it has the value 0 from the initialization and not 0xA2.

@jgromes
Copy link
Owner

jgromes commented Apr 2, 2024

Thanks for pointing this out! I'm currently working on a significant rework of the SPI interface to support new radio modules, and this is one of the things that will also be reworked. Looking into my WIP code, I have already used numBytes=1, so this will be fixed once the update is rolled out ;)

@jgromes jgromes self-assigned this Apr 2, 2024
@jgromes jgromes added the bug Something isn't working label Apr 2, 2024
@jgromes jgromes added the resolved Issue was resolved (e.g. bug fixed, or feature implemented) label Apr 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working resolved Issue was resolved (e.g. bug fixed, or feature implemented)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants