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

Error in _lx_nor_flash_driver_read and potentially elsewhere with zero starting flash address and extended cache. #13

Open
maxkunes opened this issue Dec 30, 2021 · 3 comments
Assignees

Comments

@maxkunes
Copy link

When the extended cache is enabled AND the base address of the flash device given to levelx is zero, _lx_nor_flash_driver_read will never return.

The nor flash's base address is set, at least in my case, in my driver as follows. This is very convenient as for writing as I need to provide a flash address which is not offset by any amount. For reading from the device, I offset as necessary.

nor_flash->lx_nor_flash_base_address = 0;

When _lx_nor_flash_driver_read checks if there is a cache entry for an address, there is a check to see if cache_entry_start is non zero. This causes the caching of the first sector to fail and when _lx_nor_flash_driver_read tries to read the first sector, it will never return as it can never see the cache entry which exists.

Specifically at the very least, this line:

if ((cache_entry_start) && (flash_address >= cache_entry_start) && (flash_address < cache_entry_end))

Should not simply check if cache_entry_start is non-zero. However, I don't think the solution is just to remove that check, but I'm not sure.

Given this error, I'm concerned there are other errors in the code regarding a flash address base of zero. I'm assuming this is just a mistake, as if it was not, the init function should check for the zeroed flash address.

@maxkunes
Copy link
Author

I recently upgraded to 6.1.9, but the issue exists in previous versions also.

@maxkunes
Copy link
Author

maxkunes commented Nov 7, 2023

This is still a bug in main. The safest way around this is to pass a fake base address and correct for it in the driver callbacks.

@TheFlyvio
Copy link

I can confirm this is happening, just lost 8hs because of this error

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

3 participants