Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Ian St. John wrote:

I am building and programming a custom board without Linux. Basic embedded drivers running from SPI1,CS0 (8MB NOR Flash).
CCS version 6.1.3, compiler TI 15.15.1 LTS, custom carrier board with 1808-FX-225-RC (MityARM 1808) SOM.
I can flash a standalone program.
I can start up, configure interrupts, gpio, pll, pinmux, etc.
The project is to use codecs configured over I2C, reading from McASP on a custom high speed data acquisition carrier board.
An accident with the power supply destroyed the I2C0 controller (apparently), so the system was reconfigured to use SPI1 (SPI0 conflicts with UART2)

Code is mostly based on FlashAndBoot version 2.40 (after checking against CL version 2.27)
I tested reading the FLASH (SPI, CS) and had no problem verifying access to the eeprom (reading address width, manufacturer id and jedec code). It works.

The eeprom is on the i2c0 bus. I'm assuming you are talking about the SPI Nor flash which is on SPI1_CS0.

Tried to run an external operation using the SPI1 pins and CS. No chip select operation. No clock for SPI either when trying to send a message to the codec OR when reading the FLASH (which works). i.e. no evidence that the carrier board pins work for SPI1.

You should be able to see the clock if its working for the SPI NOR so that would be my first check. Try scoping the clock on the SOM itself. The NOR is part U4. Pin 1 is the CS, Pin 2 is the MISO, Pin 5 is the MOSI, and pin 6 is the CLK. The CS pin has a pull up resistor R63 and the CLK pin has a pull down resistor R79.

The problem is that I am very confused over the SPI1 control operation trying to understand the problem.

First, working code for FLASH read.
1: The code from FlashAndBoot opens the SPI1 port in 3PIN Mode which in my reading means a direct connection, one device only, no chip select according to the tech ref.
2: Yet it calls functions to set chip select.
3: Yet there is a function in spi_mem.c that is local and will set the chip select ONLY if not in 3pin mode. HOWEVER, this function is NOT USED so it is orphan code, maybe because it doesn't work??

I'm not really familiar with running the L138/1808 without the use of u-boot and linux. Maybe someone else can clear this up.

So, the SPI1 must be working to read the 8MB flash (and boot up) but why are there no signals on the 200 pin carrier. Pinmux setup is attached, but
1: Pinmux is being set and settings confirmed.
2: The SPI1 data in, data out, clock and chip select are configured for the 200 pin connector.

If the FLASH is indeed directly connected in 3wire mode (no daisy chain of other peripherals, why would those pins (i.e. the 8 chip selects) be carried to the carrier board?

SPI Flash should be configured to work with chip select. Its chip select has a pull up resistor which should need to be driven low in order to talk to it.

Can anyone give me a clue here?

Sorry for the late reply.

The eeprom is on the i2c0 bus. I'm assuming you are talking about the SPI Nor flash which is on SPI1_CS0.+

Oops. Sorry, I said eeprom when I meant the 8MB flash. The JEDEC result is from FLASH, so ok. I modified the code to do the checks (address width, manufacturer, jedec, etc) so I could check it.

You should be able to see the clock if its working for the SPI NOR so that would be my first check. Try scoping the clock on the SOM itself. The NOR is part U4. Pin 1 is the CS, Pin 2 is the MISO, Pin 5 is the MOSI, and pin 6 is the CLK. The CS pin has a pull up resistor R63 and the CLK pin has a pull down resistor R79.

Thanks for the schematic. I'll have my hardware partner do that now that he has a guide. We did try to see the clock and chip select on the 200 pin carrier board, but were unable to see any signals. Trying to get the chip select working as a first step.

Note: I should have gotten back to this earlier. I have found SOME answers to how the FlashAndBoot code works. The SetupSpiMode is NOT properly modular. It has a hardcoding for the CS0 chip select as GPIO as a side effect. Tehre should be a separate function to set up chip select as GPIO. I modified the code (passing is a chip select index) for testing from

switch (mode) {
    case SPI_MODE_3PIN:
        SPIx->SPIPC0 =  0
                    | ( 1 << 11 )   // SOMI
                    | ( 1 << 10 )   // SIMO
                    | ( 1 << 9 );   // SPI_CLK
        SPIx->SPIPC4 |= (1 << 0) ; // set GPIO before enable to 1 (off)
        SPIx->SPIPC1 |= (1 << 0) ; // Make CS a GPIO output
        break;
    case SPI_MODE_4PIN_CS:
..

to

switch (mode) {
    case SPI_MODE_3PIN:
        SPIx->SPIPC0 =  0
                    | ( 1 << 11 )   // SOMI
                    | ( 1 << 10 )   // SIMO
                    | ( 1 << 9 );   // SPI_CLK
        SPIx->SPIPC4 |= (0x01 << (chipsel & 7)) ; // set GPIO before enable to 1 (off)
        SPIx->SPIPC1 |= (0x01 << (chipsel & 7)) ; // Make CS a GPIO output
        break;
    case SPI_MODE_4PIN_CS:

However, still no joy.

My issue(s) have reduced down to the fact that I cannot see even the FLASH SPI reads clocking (on the carrier board connnection) even when the FLASH read is working and my modification to configure a different chip select on open doesn't seem to function. Still reading the reference. I'll update this a bit later after we do some hardware testing.

Can you confirm that the signal marked as 'reserved' just beside the SPI1_CSC¹ is the SPI1_CSC⁰ and would that show the chip select operation from reading the flash? It seems a good inference but it is speculative on my part.

Hmm. I asked the EE about the diagram and he was interested in the fact that there was a pull up on the CS line. Apparently, none of our documents state that the SPI1_SCS¹ is "open drain".

We have
"am1808 tech ref (spruh82a)".pdf
"am1808 (datasheet).pdf
"ARM Architecture Reference Manual".pdf
"ARM926EJ-S Technical Reference Manual".pdf

Only the spruh82a describes the SPI peripheral and there are WAY too many "see your processor specific document" which drives me a bit round the bend as how more specific can you get than the "1808/1810 technical reference"?

Can you tell me where they say that the SPI chip selected are open drain? Which document? Page?

Ian St. John wrote:

Can you confirm that the signal marked as 'reserved' just beside the SPI1_CSC1 is the SPI1_CSC0 and would that show the chip select operation from reading the flash? It seems a good inference but it is speculative on my part.

I'll have to check on Monday.

Hmm. I asked the EE about the diagram and he was interested in the fact that there was a pull up on the CS line. Apparently, none of our documents state that the SPI1_SCS¹ is "open drain".

We have
"am1808 tech ref (spruh82a)".pdf
"am1808 (datasheet).pdf
"ARM Architecture Reference Manual".pdf
"ARM926EJ-S Technical Reference Manual".pdf

Only the spruh82a describes the SPI peripheral and there are WAY too many "see your processor specific document" which drives me a bit round the bend as how more specific can you get than the "1808/1810 technical reference"?

Can you tell me where they say that the SPI chip selected are open drain? Which document? Page?

I'm not sure about this and I can't find anything specifying it either way. My guess would be that the pull up is to ensure the device stays disabled if the processor isn't configured to use the spi. Such as if someone was to pinmux the spi pins for another purpose. But I'll ask our hardware guys.

The dispersed documentation for the L138 family trips me up too whenever I have to look through it. Can never remember if I need to look in the datasheet or the TRM or one of the other documents..

Any chance you could boot using u-boot and try to get the spi communications working there first? Or perhaps the driver will help you find some bug in the code your using. http://support.criticallink.com/gitweb/?p=u-boot-mitydspl138.git;a=blob;f=drivers/spi/davinci_spi.c;h=07b2432a98fc9bda4fdceafc3a0fd200f9b27b55;hb=refs/heads/master

Johnathan,

Joy Joy, Happy Happy.

Everything is working. There were three items altogether. First was the "open drain" on the chip select. The EE added a pull up resistor and that worked). We were able to finally capture the spi signals on the scope (might have been finger trouble) and a second item came up (coding error). Add a documentation slip on the codec datasheet and we were off and running. Thanks.

Excellent glad you got it working.