xRM46L852PGE mibSPI1 strange problem

Hello Dmitri,

I will check on this behavior with our design team to see if there is any limitations that would only affect MibSPI1; however, I think the implementations should be the same. MibSPI5 IP supports parallel mode SPI which may be enough difference in the logic to somehow cause an unintended side effect. Once I have more insight, I will get back to you with further explanation.

Hello Dmitri,

Out design team has reviewed your description of your setup and the behavior you are seeing is not as they would expect. Is it possible for you to post your project to this thread so we can review your setup and generate a test code for our design team to simulate what you are seeing? This will allow them to trace through the design to see what might be causing the problem or to see if there is something in your setup that needs to be changed.

Hi Chuck,

The application is quite big now  to post it as it is. The spi3 master is working with DMA and all other slaves are read by DMA  as well so it makes hard to demonstrate it inside the app. What I can do, I may cut  out the spi code and  make a small test based on the setup  do demonstrate the problem. I would come to you later with the test result.  

Regards, Dmitri. 

Hi Chuck,

I isolated the code. It is not exactly the same as the application is using but it shows the problem. It was run on our board with xRM46L852PGE chip installed. Hardware wiring: mibSPI3 is the master clocking  (pin 53 )three 16 bit ADC chains (2 ADCs per chain, 6 in total ),  mibSPI1 (pin 95) and mibSPI5 (pin100) .  minSPI3 nSC0 (pin 55) is connected to ADCs, nCS5 for mibSPI1 (pin 91) and nCS0 for mibSPI5 (pin 32). ADC data lines are connected to mibSPI1 SIMO (pin 93), mibSPI3 MISO (pin 51), mibSPI5 SIMO (pin 99). As you can see SPI3 and SPI5  have data received; value ~16390 is valid code representing  the signal. Receiver flags show CS0. SPI1  receives only when SOMI is enabled.     

Here is the output from the test :

The project code is attached:

5460.mibSPI1_TEST.zip

Regards, Dmitri.

Dmitri,

I was able to reproduce your problem on our HDK board.
Can you confirm that the Halcogen project part of your zipped project is the one use to generate your application?
I've tried to load it and can't see the correct definition for MIBSPI1, 3 and 5.
So for now I'm using your generated code to see how everything is configured.

In Multi Buffer Slave mode (MIBSPI1 and MIBSPI5 in your application) the CS lines are used to select which transfer group has  to be used.
Using CS5 is not possible. Only CS0, CS1, CS2 and CS3 can be used.

The following table assume all CS[3:0] are defined as functional.

CS3 CS2 CS1 CS0
   0       0       0      0        Trigger TG0
   0       0       0      1        Trigger TG1
   0       0       1      0        Trigger TG2
   0       0       1      1        Trigger TG3
   1       1       1      1        Not selected

Based on the number of TG your application needs, the number of CS to be used is configurable . If the CS is defined as functional, it will be used in the decode process.
In your case, if only 1 TG is necessary, than only configure CS0 as functional and all other as GIO.

Note: If you need more than 1 TG you will need more than 1 CS line between your master and your slave.
It is also necessary to configure the master to generate "Encoded CS" instead of one hot CS.

I understand that the TRM does not cover the MIBSPI in slave mode efficiently. We are working on a revised section for MIBSPI.

Please let me know if I've answered your question and let me know the result for your application.

Hi Jean-Mark,

The halcogen project was used for start up sequence generation only. Part of the code is based on halcogen generated code but not from this project and that code was modified. This is why you don't see proper chip select allocation - it was done manually based on actual hardware.

Be honest I don' t understand the table you placed. It goes against TRM, you own API, and actual chip behavior.   

As I mentioned in my original post, I found the walk around and it is not affecting my application, since we don't allocate SOMI line for mibSPI1. 

Regards, Dmitri. 

Hi Jean-Mark,

As you can see in my post showing a debug listing, SPI1 slave is perfectly triggered by SC5 line configured for TG0. CS5 was decoded in the status register (0x1F). 

Regards, Dmitri.

Hi Jean-Marc,

Thanks for the explanation. If it is real spi design it should be in TRM since it doesn't mention any chip select decoder in spi's design description, not in buffer's description.  Anyway even SPI1 is  working in 3 pin mode, it doesn't explain why  it needs SOMI to be functional.   

Regards ,Dmitri.

Hi Jean-Marc,

I changed the spi1 select line to CS4 and disabled CS5. Yes it receives anyway with no CS active ( CS4 line is steady high)  which confirms you are right saying the spi1 doesn't care of CS at all and works in 3 pin mode synchronizing on the clock.

Actually, all of this kills spi1 as slave with CS on PGE because CS[0-2] are heavily multiplexed with USB and MII and SC3 doesn't exists on PGE package.     

Regards, Dmitri

Dmitri,

You only need all CS[3:0] if you want to be able to trigger up to 15 Transfer Group in your MIBSPI1.
If you only need 1 TG, CS0 is enough.
Do you use USB or MII in your application?

By doing more test using Halcogen, I've found some limitation in the generated code.
Mainly Halcogen supports Master mode in the Transfer Group Tab.
I will contact the software team to see what can be done to make is easier.
At least, if the SPI is defined as Slave, the Transfer Group Tab should have some parameters grey out (Not applicable).
Another point to highlight is in the definition of the CS for a given TG. Halcogen does not provide a way to used encoded CS. This is a limitation that should be fixed.

Hi Jean-Marc,

Yes, USB0 is used and all other  CS pins are allocated as well. The only possible pin would be CS2 but it is also used already and, anyway, it is too late to reallocate it - the board is done. We will live with 3 pin mode.

Regards, Dmitri.