SPIMaster - can both CS lines be active?

[u77345]

I need to drive 3 SPI devices, so I decoded the CE0 and CE1 with an LS139, to derive 3 chip select lines. Now I can use the 0, 1 and SPIMaster's ChipSelectNone to drive nChipSelect, and it all works well (except not getting any CS with ChipSelectNone). When I fuzz ChipSelectNone the kernel stops - I assume on an assertion. Is there any way to get the ARM SPI drive both CS lines low? If I try to directly manipulate the GPIO, the logic analyzer trace shows glitches all over the CS lines. The test board is a Raspberry Pi Model B R2.

[rsta2]

No, unfortunately the SPI master peripheral does not allow to drive two CS lines low at the same time. Which assertion is it? I cannot see a problem in the source code of the CSPIMaster class.

[u77345]

Can I take full control of the lines with GPIO and use ChipSelectNone on the peripheral? It would solve it for me elegantly. I assumed assertion as the kernel stops with nChipSelect=2.

Is there a way to log the assertion failure? I’m using the serial log, not the screen based.

[rsta2]

Yes, this should work. You have to use separate CGPIOPin instances for the CS lines and create them after (!) the CSPIMaster instance. ChipSelectNone is equal to the value 3, not 2. nChipSelect = 2 is not allowed, because there are only two CS lines from the peripheral (0 and 1) routed to the GPIO header.

Most Circle samples direct the logger output, including assertions, to the serial interface, when you add the option logdev=ttyS1 to the file cmdline.txt on the SD card.

[u77345]

Workable solution, thanks! Two small concerns:

1. Given I need to set the GPIO lines one after the other, I'm getting 250ns wide glitches on the decoded LS139 output. Would there be a way of applying a bit mask over the GPIO wider register in one write?

2. I have log level = 4 and logdev=ttyS1 in cmdline.txt, but did not catch the assertion.

[rsta2]

You are welcome.

1. Have a look at the static method CGPIOPin::WriteAll().

2. Do you see any other messages from the logger? If so, you should also see the "assertion failed" messages. There is one exception: The assertion fails in an IRQ handler and you have the system option REALTIME enabled. In this case messages from an IRQ handler won't be displayed.

BTW. It can also be an exception. Do you have the class CExceptionHandler instantiated? This is necessary to see exception messages, when one occurs.

[u77345]

WriteAll() solved it - thanks Rene.
Yes, I have CExceptionHandler instantiated, and did not see the exception or assertion message in the log. I'll rest the research on the silent crash for now, until it pops back in again.