SAMD21 and SPI Flash N25Q512A - Max CLK Frequency

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

Hi all,

 

I have this issue with the SPI communication between the SAMD21G18 and a N25Q512A flash device, where it seems I cannot go behond 8MHz clock. (7.999.999 works, 8.000.000 works, 8.000.0001 and behond do not)

 

General setup:

- Using SERCOM3, in DMA mode

- GCLK_GENERATOR_0, clk=48MHz

- Using the ASF framework

 

I have checked the actual electrical IF, and even if I set 16MHz clock, then the transmision towards the N25Q512A is correct, even the responses of the N25Q512A are correct. However the SAMD21 seems not to receive the correct data. If I use the normal bytewise ASF like:

	FLASH_CE(1);
		spi_write_buffer_wait(&flash_spi_master,cmd,1);
		spi_read_buffer_wait(&flash_spi_master,&configReg.bytes,2,0);
	FLASH_CE(0);

then I can go upto 12MHz but also behond there it stops. On the same device I also use a SPI LCD (ILI9341 driver) and there I can transmit at 24MHz without error. As I am transferring data from the Flash towards the LCD it would be good to increase the reading speed of the flash to somewere around 16MHz.

 

As the boundary is exactly at 8 MHz, it seems there is something wrong internally inside the SAMD21, not so much witht he PCB layout. The signals look fine electrically (rise times etc).

 

I also discovered that if I put 12MHz into the SPI config like:

config_spi_master.mode_specific.master.baudrate = 12000000UL

the electrically measured clk frequency is around 12MHz. However, if I put in 12.000.001 than the clk jumps to the maximum 24MHz...is this normal?

 

Anyone a sugestion?

 

Thanks,

Peter

 

Last Edited: Mon. Feb 15, 2016 - 04:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You might want to check that the phase and clock polarity settings are correct. This might explain the speed sensitivity. Look at the clock edge the mosi signal changes. Compare this with the spi flash data sheet.

The jump in clock frequency looks like integer roundup in the ASF code. Step through the code to see what it does. Bugs aren't unusual in ASF.

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

The answer your question is yes. Why... 

 

You have to look at the baud rate options for synchronous mode. The formula states fbaud <= fref/2, and fbaud = fref/((2*(BAUD+1)).

 

There is not a factional divider for the baud register in the SERCOM.

Given fref=48e6:

Baud = 0, fbaud = 24MHz

Baud = 1, fbaud = 12MHz

Baud = 2, fbaud = 8MHz

Baud = 3, fbaud = 6MHz

Baud = 4, fbaud = 4.8MHz

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

Ok, The baud rate I also figured out.

 

However, there seems to be something internally wrong with the MISO line. Below is a screen shot (with camera, could not find a usb stick) of the clock and the MISO, directly at the inputs of the SAMD21.

 

SPI mode=3.

 

As you can see, this should be a 0x20, however the SAM reads 0x10. The 0x20 is the correct value (JEDEC ID of the Flash). There is a shift of 1 bit. Also the following bytes have this shift. Next byte should be 0x10 but SAM tells me 0x08 etc.

 

For me it seems there is an internal delay of the MISO line. I also run out of ideas. I can delay signals but I cannot advance them. Did someone saw this issue as well? Is there any solution?

 

Thanks,

Peter

 

 

Last Edited: Tue. Feb 16, 2016 - 09:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are you using 10:1 probes on the 'scope? Both probes grounded? The signals do not look good.
The miso data changes on the falling edge and is clocked in on the rising. I read 0010

Just had a quick read of the datasheet. Port.pincfg.drvstr should be 1 for high speed port drive. Enable this on the spi output pins and the clock should look better.

Last Edited: Tue. Feb 16, 2016 - 12:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks for your reply. Yes, 10:1 probes and grounded. However the trigger was on the falling edge of the SS signal and I zoomed in, therefore the signal is a little "under sampled". I also have QFN packages so I needed to solder small wires onto the pads to be able to connect a probe. Therefore, signal not optimum.

 

Thanks for the hint on the DRVSTR, this is normally disabled for the SAMD21 inside the ASF(FEATURE_SYSTEM_PINMUX_DRIVE_STRENGTH in pinmux.h)..I enabled and set these bits on the MOSI and CLK line and it seems a little better clk but oveall the symthoms do not improve, still bit shift and reading 0x10 in stead of the 0x20:

 

SPI-MODE=3:

TOP: SCLK

BOTTOM: MISO

 

SPI-MODE 0:

TOP: SCLK

BOTTOM: MISO

 

For me the signal looks good enough for the SAM to be able to sample this properly. I have no clue why it shifts by 1 bit, must be something internal or is there some other setting which I missed?

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

Perhaps the problem lies with ASF.

 

Using a 12Mhz SPI clock in mode 3, reading Read Manufacturer and Device ID on the AT25DF081A (SAMD21-XPRO board, no ASF, simple loop).

 

I get what I would expect:

 

Instrument screen

 

 

int main(void)
{
  CLOCKS_OSC8M_Init();
  CLOCKS_DFLL_Init();
  CLOCKS_EnableUsedClocks();
  SERCOM5_Init();
  /* load OPCODE for Read Manufacturer and Device ID */
  dout[0] = 0x9F;

  while (1)
  {
    /* read forever */
    TransferSpi(6);
    cnt++;
  }
}

void TransferSpi(uint8_t cnt)
{
  if (cnt > 0)
  {
    PORT_IOBUS->Group[0].OUTCLR.reg = PORT_PA13;
    for (uint8_t i = 0; i < cnt; i++)
    {
      SERCOM5->SPI.DATA.reg = dout[i];
      /**/
      while (0 == SERCOM5->SPI.INTFLAG.bit.RXC);
      din[i] = SERCOM5->SPI.DATA.reg;
    }
    PORT_IOBUS->Group[0].OUTSET.reg = PORT_PA13;
  }
}

 

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

Correct, I get the same result using the normal byte wise approach:

FLASH_CE(1);
		spi_write_buffer_wait(&flash_spi_master,cmd,1);
		spi_read_buffer_wait(&flash_spi_master,&configReg.bytes,2,0);
FLASH_CE(0);

kind of similar as you are doing it. In this case I can also reach 12MHz(see first post). However, in this scenario the SPI clock is not so important as the delay between the bytes is much bigger so this basically means that the effective speed is determined by the pauses between the bytes and not the SPI clock itself. If you use the DMA approach the SPI clock is the dominating factor in the equation. In the DMA approach, the ASF is not involved except for setting up the transfer but this basiclly works for F<=8MHz, so i do not see why ASF should behave different if the clock is increased.

 

Can you try to put the SPI clock to 24MHz and see if you still can read the JEDEC ID? (In my case it also stops after 12MHz in the byte-wise-approach)

 

Thanks!

Last Edited: Tue. Feb 16, 2016 - 09:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With these frameworks, when things don't make sense i look at the peripheral registers to see exactly how they configured the peripheral.
The clock looks much cleaner now and we can easily see miso change on the falling edge. What we don't know is what edge the sercom is sampling. We can get an idea by 'scoping the mosi and seeing what edge it changes on.

With the debugger you can stop the code, change the sercom settings by changing the register values live then running the code and observing the results.

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

I do not get correct SPI data read in on the MISO pin at 24MHz clock (baud=0) when the peripheral and CPU at 48MHz.

Instrument screen

However if I change the peripheral clock to 8MHz with the baud=0and the CPU=48MHz, The data in is read correctly.

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

Maybe time to check the errata and contact Atmel.

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

just to give an update...conclusion is that I gave up on the Clock...Next HW version will have a SAMG, which allows general much higher clocks.

 

I have found following things, maybe it helps someone else:

 

Found an "errata", aka FAQ: http://atmel.force.com/support/a...

This one specifies the clock as 12MHz maximim. With this information, i took a closer look into the datasheet and found on page 988 that the maximum SCK period is 84ns, which is 12MHz...My experience is that this is only valid for reading (MISO), the writing (MOSI) can easilly go upto 24MHz, which I actually use for the LCD and this works without any pixel failures, always...It is however outside the specified range so if you are making professional product better not to do that...

 

Even with the maximum of 12MHz, the DMA version does not work. Here again the writing (MOSI) has no problems, but again it is the input. In this case, the RX-done interrupt is never comming. I get the TX-Done IRQ but never the RX-Done. This scenario is very difficult to debug but it has nothing to do with the ASF as it does not do anything than abstracting the register writing (I checked that).

 

I guess the SAMD devices have some problems on the MISO input. If you use the byte-wise approach (so spi_read_buffer_wait and spi_write_buffer_wait), 12MHz works perfectly. Fo the DMA version, 12MHz does not. However, with the byte-wise-appraoch I personally doupt that you will see significant speed increase if you switch from 8Mhz to 12MHz, so it is not worth the hassle ;)

 

From my side, we can close the topic...I will switch devices :-D

 

Thanks for the help!

 

 

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

Similar problems here...

I'm using a SAMD21XPlainedPro Board with Atmel Studio 7 and Atmel Start Configuration. 

(See Attachments for details and settings)

 

I need fast SPI for a LCD-Graphix-Modul with MIN System cycle time (8bit) @ 4wire: 145 ns 

Thus I want to work with ~ 8 MHz. 

 

Problem: I'm getting nice and clean signals but there is to much time elapsing until the next byte starts transmitting. 

Raising the CPU/ System Clock to 48 MHz / 24 MHz/ and 12 MHz has no effect... resp. --> For high CPU Frequencies (like 24 MHz and above) the SPI Clock-Line has no output ... 

Only baudrate as found out by myself changes some characteristics of the SPI SLCK Signal

why??

 

I'll add some scope screens soon!

Attachment(s): 

Last Edited: Wed. Mar 8, 2017 - 11:04 AM