nRF52840 QSPI - Truncated Read/Write Lengths

[AGlass0fMilk]

Description

I have discovered a bug with the nRF52840 QSPI hal driver while trying to get some examples to work. I was only seeing partial data being read back. The example was trying to write "hello\0", but when read back it would only product "hell"... as if the bug was trying to speak to me.

I narrowed it down to a fine print item in the nRF52840 datasheet concerning the length of QSPI read/writes (see attached screen captures):

Read/Write chunks must be multiples of 4 bytes. The current HAL driver simply populates this register from the user's input. In my toy case, this results in 6 being written to the READ.CNT and WRITE.CNT registers, where the nRF52840 ignores the lower bits and truncates the transfer lengths to 4 bytes.

See the functions here that call the underlying Nordic driver functions:

mbed-os/targets/TARGET_NORDIC/TARGET_NRF5x/qspi_api.c

Lines 248 to 277 in d30ae07

	qspi_status_t qspi_write(qspi_t *obj, const qspi_command_t *command, const void *data, size_t *length)
	{
	qspi_status_t status = qspi_prepare_command(obj, command, true);
	if (status != QSPI_STATUS_OK) {
	return status;
	}
	// write here does not return how much it transfered, we return transfered all
	ret_code_t ret = nrf_drv_qspi_write(data, *length, command->address.value);
	if (ret == NRF_SUCCESS ) {
	return QSPI_STATUS_OK;
	} else {
	return QSPI_STATUS_ERROR;
	}
	}
	qspi_status_t qspi_read(qspi_t *obj, const qspi_command_t *command, void *data, size_t *length)
	{
	qspi_status_t status = qspi_prepare_command(obj, command, false);
	if (status != QSPI_STATUS_OK) {
	return status;
	}
	ret_code_t ret = nrf_drv_qspi_read(data, *length, command->address.value);
	if (ret == NRF_SUCCESS ) {
	return QSPI_STATUS_OK;
	} else {
	return QSPI_STATUS_ERROR;
	}
	}

If you need any other information or want me to upload my toy code, let me know.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

[AGlass0fMilk]

Potential solution (I may do a pull request later but I don't have time right now):
For reads: round the transaction length up to the next multiple of 4 and throw away additional bytes when returning data to application

For writes: round the transaction length up to the next multiple of 4 and pad the transaction with 0xFF, which will prevent flash bits from being flipped (so they can still be programmed later on).

Rounding math (thanks stack overflow): (len + 3) & ~0x03

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-23

[j3hill]

This issue is being addressed in this pull request: #8832 . The Nordic nRF52 target "qspi_api.c" is being updated to check for WORD (4 byte alignment) on QSPI reads and writes. Please note that BufferingBlockDevice can also be used on top of the Mbed OS QSPIFBlockDevice to support the Macronix MX25R6435F flash part within the nRF52840 DK development board.

[0xc0170]

Thanks @AGlass0fMilk for the detailed report with proposed solution

[j3hill]

@AGlass0fMilk This issue has been address in Mbed-OS pull request (PR) #9291 (#9291). The QSPIFBlockDevice returns the nRF52840 4-byte read/prog requirement to the LittleFS file system. LittleFS then manages the flash storage reads/writes to accommodate this QSPI hardware requirement. Please note that this PR also adds support for QSPI SFDP reads with the nRF52840.

[j3hill]

@AGlass0fMilk There have been two more PR's to address the issues highlighted here. Here is the PR to address the "Word-aligned RAM source address" requirement: #9866 . Here is the PR to address the truncation problem in the QSPI example you mentioned at the top of this thread: ARMmbed/mbed-os-example-qspi#2