Drivers: Mbed application shield fails in Mbed OS 5.15.0 - LCD Screen SPI interface

[froeba]

Description of defect

Using the sample code for the C12832 LCD screen on an Mbed Application Shield:

• https://os.mbed.com/components/mbed-application-shield/
• https://os.mbed.com/users/sarahmarshy/code/app-shield-LCD/

This causes an error at runtime as one of the pins is set to NC

++ MbedOS Error Info ++
Error Status: 0x80FF0144 Code: 324 Module: 255
Error Message: Assertion failed: pin != (PinName)NC
Location: 0x800A6C3
File: ./mbed-os/targets/TARGET_STM/pinmap.c+62
Error Value: 0x0
Current Thread: main Id: 0x10001978 Entry: 0x800ACAD StackSize: 0x1000 StackMem: 0x100007F8 SP: 0x100011C8
For more info, visit: https://mbed.com/s/error?error=0x80FF0144&tgt=DISCO_L475VG_IOT01A
-- MbedOS Error Info --
= System will be rebooted due to a fatal error =
= Reboot count(=713) reached maximum, system will halt after rebooting 

This appears to be due to the SPI in C12832 being declared with miso == NC which was acceptable in mbed os < 5.15

The SPI.h file indicates that it is okay for miso to be set to NC

• https://github.com/ARMmbed/mbed-os/blob/master/drivers/SPI.h#L109

Target(s) affected by this defect ?

Tested and fails in:

• K64F
• DISCO-L475VG-IOT01A

Toolchain(s) (name and version) displaying this defect ?

Fails in both:

• mbed-cli with gcc_arm
• mbed studio 0.8.1 with Arm C6

What version of Mbed-os are you using (tag or sha) ?

• mbed-os-5.15.1 <- fails
• mbed-os-5.15.0 <- fails
• mbed-os-5.14.2 <- succeeds

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

• mbed studio 0.8.1
• mbed-cli 1.10.2

How is this defect reproduced ?

Create above sample code and run on the device with mbed os 5.15 or above

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2547

[jeromecoutant]

Hi

C12832 is using _spi(mosi,NC,sck)

Issue came with static pinmap feature.

@mprse

[0xc0170]

I looked at this briefly with @bertfroeba . It looks like static pinmap feature made some changes that affect this. It is in the generic implementation for spi.

@mprse would you be able to look at this?

cc @ARMmbed/mbed-os-hal

[mprse]

Yes, I'm looking into this right now.

[mprse]

@jeromecoutant @0xc0170

While working on the fix for this issue I noticed some inconsistency I need consultation.
As mentioned on this issue:

mbed-os/drivers/SPI.h

Line 109 in c12b433

* @note You can specify mosi or miso as NC if not used.

In our driver's layer, we assume that we can specify MISO or MOSI as NC if we want to use only one data line (only send data to the slave device or only read from the slave device). In the STM HAL implementation, we allow configuring SPI into a 3-wire mode (half-duplex) when MISO = NC. As far as I understand in 3-wire/half-duplex mode is something else than unused line (in half-duplex mode one line is used for sending and receiving data):

mbed-os/targets/TARGET_STM/stm_spi_api.c

Lines 248 to 252 in c12b433

	if (pinmap->miso_pin != NC) {
	handle->Init.Direction = SPI_DIRECTION_2LINES;
	} else {
	handle->Init.Direction = SPI_DIRECTION_1LINE;
	}

On the SPI feature branch, we allow 3-wire mode, but I'm not sure how this should work here. Should we drop configuring half-duplex mode if MISO is NC? Or update the comment in the SPI.h and inform that when MISO or MOSI is NC the bus may be assumed to be half-duplex if the hardware supports this?

[LMESTM]

@mprse

The SPI_DIRECTION_2LINES is indeed an ST implementation choice for a specific sensor that works only in 3-wire mode. that means that MOSI line will be used to send and to receive data. The MISO line is declared as NC and is indeed Not Connected (and not used).

The comment in SPI.h just states that if NC the line is not used, it doesn't say that you will only write or only read, so I 'm not sure which inconsistency you're seeing ?

When the driver tries to read from an SPI driver instance configured with MOSI only, then it assumes the 3-wire mode. In a case of a Display driver, I would assume that it will only write and not try to read at all ...

What is the actual problem ?

[mprse]

@LMESTM Thanks for the response. I will leave 3-wire mode available, create a patch and ask for a review.

[mprse]

Fix can be found here: PR #12460.

[jeromecoutant]

@0xc0170 can we close this one ?
Thx