AT M90E32AS SPI Read/Write Data Loss

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi There,

I have a question about using the M90E32AS and its SPI registers. I believe I am having some timing issues but I can't determine at which point they occur.

I'm using a SAM3X chip and have set the SPI speed to 1MHz. I've tried to follow along the wait times according to the datasheet on page 76.

 

Basically, I start out by calibrating the registers and setting the offset/gain registers etc.

When I step through the code in debugging mode, I do not experience any problems, the registers set and I can keep stepping through the code and get very accurate current, voltage and power readings.

However, when I run the code at full speed, the CfgRegAccEn does not take the initial value to allow offset/gain writes to the chip (it remains at 0xFFFF instead of changing 0x55AA). I am still getting Urms and Irms values that correspond with the default gain, but obviously, without the offset and calibration they are not correct.

 

These timings are recommended in the datasheet so I have:

Write register:

 Assert CS

 Wait 8us

 Transfer register

 Wait 3us

 Transfer data

 Wait 2us

 Disable CS

 Wait 3us

Read Register:

 Assert CS

 Wait 8 us

 Transfer register

 Wait 3us

 Read data

 Disable CS

 Wait 3us

 

I think the reads are working just fine but nothing gets written to the registers (and I confirm this by checking the value immediately after). Am I misinterpreting the datasheet? What are the timing requirements for this chip other than what I've seen in the datasheet?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So it "works" in single-stepping, but not at "full speed"?

 

That very much suggests a timing issue - doesn't it?

 

Have you actually looked at the transactions on  the wires?

 

kudruu wrote:

Write register:

 Assert CS

 Wait 8us

 Transfer register

 Wait 3us

 Transfer data

 Wait 2us

 Disable CS

 Wait 3us

Read Register:

 Assert CS

 Wait 8 us

 Transfer register

 Wait 3us

 Read data

 Disable CS

 Wait 3us

 

What do you mean by "transfer register" ?

 

Is that where you send the register address ?

 

How do the above steps relate to your single-stepping?

 

These timings are recommended in the datasheet

Where? 

 

I don't see them in this datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-46003-SE-M90E32AS-Datasheet.pdf

 

The timing diagram doesn't suggest any gaps or delays:

 

 

 

Is there any Atmel/Microchip example?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is a timing diagram on page 76, but I may be reading it wrong. Here is what it looks like when it fails to properly write - the bottom line is CS (I am assuming that the read is accurate):

 

Then, a blown out version of stepping through the debugger, where you can see from the transactions on the right side that it has written to the register.

 

So I agree that it is a timing issue, but I'm not entirely sure where. There's nothing in the App note about the mechanics of writing to the SPI registers, only in the datasheet (page 76, chapter 6.3). But maybe I am misinterpreting the way the timing table is written. But I can't be doing SPI writes that take 5 seconds to complete. I thought I had calculated the delays according to the datasheet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Figure-22 timing diagram is the per-bit timing - it's not about delays that you insert between sending the address & reading the data - as your opening post suggests.

 

See the Figure-17 & 18 diagrams that I posted.

 

Do you have the correct SPI mode ?

 

As there is a demo board, there must be demo software. It doesn't seem to be published on the web, so have you contacted Microchip/Atmel to request it?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kudruu wrote:

Read Register:

 Assert CS

 Wait 8 us

 Transfer register

 Wait 3us

 Read data

 Disable CS

 Wait 3us

 

Why is there no delay between Read Data and Disable CS ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the clarification. I should have the correct SPI mode, I am using other SPI devices and I set the registers directly. I don't think I would be able to step through or read data if I had not selected the correct mode.

 

I have not contacted them for demo software but I will now, thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Why is there no delay between Read Data and Disable CS ?

Because the t_df (Output Disable Time) has a 'Max' spec of 2T+20, or in my case, 2020ns. The time to disable CS already takes 2us.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suggest that you configure your Saleae Logic Analyser in a more intuitive way.
Personally, I place CS, MOSI, MISO, SCK in top to bottom order. And view all the channels at minimum height with clear view of each transition. Your 1MHz SCK needs 8M Samples per second.
.
Please check the SPI mode settings. I find it very odd that the blue 0x55AA extends past the CS active period.
.
Your use of SAM3X suggests an Arduino Due. I would develop with Arduino SPI class.
When debugged, I would rebuild for bare metal SAM3X code. But get your Saleae settings correct first.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
Personally, I place CS, MOSI, MISO, SCK in top to bottom order. 

It is, of course, a personal preference, but all the datasheet timing diagrams for this chip have CS, SCK, MOSI, MISO in top to bottom order - so that might be a good choice for direct comparison with the datasheet ...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I suggest that you configure your Saleae Logic Analyser in a more intuitive way. Personally, I place CS, MOSI, MISO, SCK in top to bottom order. And view all the channels at minimum height with clear view of each transition.

I hadn't realized I could drag the channels around, thanks.

 

david.prentice wrote:
Your 1MHz SCK needs 8M Samples per second.

Good point

 

david.prentice wrote:
Please check the SPI mode settings. I find it very odd that the blue 0x55AA extends past the CS active period.

I thought that had to do with the delay. Here's an updated image.

 

david.prentice wrote:
Your use of SAM3X suggests an Arduino Due. I would develop with Arduino SPI class. When debugged, I would rebuild for bare metal SAM3X code. But get your Saleae settings correct first.

Custom board running ASF.

 

As specified in the datasheet,

In the SPI mode, data on SDI is shifted into the chip on the rising edge of SCLK while data on SDO is shifted out of the chip on the falling edge of SCLK.

This corresponds to spi_mode_0. So I set my register

SPI->SPI_CSR[_cs] = ((SPI_MODE_0) || SPI_CSR_CSAAT | SPI_CSR_SCBR(frequency) | SPI_CSR_DLYBCT(0x10)); //set data mode and delay
SPI->SPI_CSR[_cs] &= (~SPI_CSR_CPOL); //clock is low when inactive (redundant because of the SPI_MODE_0 but I was having problems with this before when setting the registers so I do it manually)
SPI->SPI_CSR[_cs] |= SPI_CSR_NCPHA; //Data clocked in on leading edge

 

Last Edited: Thu. Sep 7, 2017 - 08:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kudruu wrote:

SPI->SPI_CSR[_cs] = ((SPI_MODE_0) || SPI_CSR_CSAAT | SPI_CSR_SCBR(frequency) | SPI_CSR_DLYBCT(0x10)); //set data mode and delay

What is the "delay" mentioned there ?

 

(remember you're posting in the AVR forum - so don't assume people know the details of SAM)

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

kudruu wrote:

SPI->SPI_CSR[_cs] = ((SPI_MODE_0) || SPI_CSR_CSAAT | SPI_CSR_SCBR(frequency) | SPI_CSR_DLYBCT(0x10)); //set data mode and delay

What is the "delay" mentioned there ?

Sorry about that...the delay here is actually not relevant to the M90E32AS. It applies to the fixed chip select mode (for some other SPI devices I'm using on the same bus). However, I am using variable chip select for this IC, meaning I assert and disable the CS manually.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since it "works" single-step, and not at "full speed", one thing to try might be significantly increasing your delays to be comparable to the manual stepping; then reduce to find where the "critical" one is ... ?

 

Instead of single-stepping the whole thing, have you tried just putting breakpoints at the start & end of the complete SPI sequences?

 

Again, the datasheet shows the complete sequences with no delays - so perhaps the problem is with timing between sequences ... ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kudruu wrote:
other SPI devices I'm using on the same bus

What happens if you remove those "other devices" and have just the M90E32AS on the bus ... ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Instead of single-stepping the whole thing, have you tried just putting breakpoints at the start & end of the complete SPI sequences?

Yes, it fails in these cases.

awneil wrote:

Again, the datasheet shows the complete sequences with no delays - so perhaps the problem is with timing between sequences ... ?

What is a sequence? An 8/16-bit transfer?

I thought that was the point behind t_dis (Data Setup Time) and t_dih (Data Hold Time) which is why I have a delay between sending the register and the data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it looks like 16-bit mode#0 SPI.
The Analyser will start analysing with active CS. And check that SCK is low when idle.
This stops when CS goes idle.
.
Your picture in #4 has got odd width blue labels.
.
A common problem is when you make CS idle before SCK has finished clocking.
The Analyser will not display a blue label for this case.
.
It should be pretty straightforward to test your chip at different speeds. Often you need a delay between CS_acrive and the first SCK transition. Subsequent SPI bytes (or words) seldom need gaps with a hardware chip.
.
Yes, LA channel order is a personal choice.
It is a good idea (tm) to mimic the datasheet diagram when you have a timing problem.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

kudruu wrote:
other SPI devices I'm using on the same bus

What happens if you remove those "other devices" and have just the M90E32AS on the bus ... ?

They are currently removed from the board, I'm just testing this one device.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
A common problem is when you make CS idle before SCK has finished clocking.

 

This seems to be the answer. I increased the time before making CS idle to 1s and it writes. It begins to fail below 100ms, which is not in accordance with the datasheet, but I suppose there is no way to make it go faster than that. Thanks for the input!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kudruu wrote:
What is a sequence?

This:

 

 

An 8/16-bit transfer?

They are 32 bits!

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kudruu wrote:
the time before making CS idle

That would be tCLD in Figure-22

 

It says the minimum is 1T - ie, one  system clock cycle

 

It begins to fail below 100ms

So what is your "system clock" for the M90E32AS

 

EDIT

 

perhaps I mean tCSD - which is (3T + 10ns) minimum

Last Edited: Thu. Sep 7, 2017 - 09:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

 

perhaps I mean tCSD - which is (3T + 10ns) minimum

 

Right, I would have thought that, because my SPI is operating at 1Mhz, this would correspond to 3*1000ns + 10ns = 3010ns for t_csd. But that clearly doesn't seem to be the case given that it won't successfully write after setting the CS pin to idle after less than 100ms, which is 33 times what the datasheet says!