External SRAM and non-multiplexed Flexbus

[michaelhuslig]

I am still confused.  Please compare the discussion in K22 Flexbus and External SRAM and Flexbus - Help Needed .  The two discussions differ on the use of A0.

I have attached my schematic which hasn't gone to prototype yet.  Can someone verify that is correct as far as the hardware is concerned?  And if it is correct, can Freescale please add it to their appnote?

Mike Huslig

[weblar]

Hi Mike,

To add my two pence, my version using A0 to FB_AD0 now works absolutely fine once I'd sorted my FB_BExx signals out.

I was more than confused when trying to figure out whether my pin mapping was correct. To be fair, I still am.

At least I now have working SRAM and LCD on the same flexbus.

Kind regards,

Kevin

[michaelhuslig]

Kevin,

Have you scoped out what is happening on FB_AD0?  If those who are saying do not use FB_AD0 are correct, you may have access to only half of your SRAM.

Mike

[weblar]

Hi Mike,

I've only done a basic verify - wrote 10000 random words, read them back and compared. Not done a full range test though.

I'm definitely open to the fact that I've used AD0 incorrectly.

I'll do more testing tomorrow and next week then will report back my findings.

Kind regards,

Kev

[michaelhuslig]

Kev,

It might be easier to do 4 8-bit writes to SRAM addresses 0, 1, 2, and 3.  And then do a 32-bit read from SRAM address 0.  And I am not sure if it reads normal whether that proves one or the other.

Mike

[weblar]

Hi Mike,

It does indeed look as if my SRAM is hooked up incorrectly.

Following your advice and doing 4 8-bit writes, every other address does not get written. Consider the following code:

// Do some byte writes to the SRAM

for (uint32_t i = 0; i < 400; i += 4) {

  uint8_t *p = (uint8_t *)&SRAM_START_ADDRESS + i;

  p[0] = 0xAA;

  p[1] = 0xBB;

  p[2] = 0xCC;

  p[3] = 0xDD;

}

Indices [1] and [3] are not being written, whereas [0] and [2] are.

Would this indicate incorrect usage of AD[0]? It would certainly mean that I can only access half of the SRAM.

Regards,

Kev

[weblar]

Hang on a second, I think I'm confusing myself again.

I've re-written the test code, checking byte read/writes, word read/writes and dword read/writes. One thing I don't seem to be able to do is to byte-write/read to odd addresses - even addresses only seem to work. However, with 16 and 32-bit writes/reads there doesn't seem to be a problem.

My code is now thus:

uint32_t i = 0;

uint8_t wr8 = 0x88;

uint16_t wr16 = 0x99AA;

uint32_t wr32 = 0xBBCCDDEE;

uint8_t rd8 = 0x00;

uint16_t rd16 = 0x0000;

uint32_t rd32 = 0x000000000;

// Test some 8-bit write and reads

for (i = 0x00; i < 0x0F; i++) {

  // Write a byte

  *(volatile uint8_t *)(&SRAM_START_ADDRESS + i) = wr8;

  // Read a byte

  rd8 = 0;

  rd8 = (*(volatile uint8_t *)(&SRAM_START_ADDRESS + i));

  printf("Addr: 0x%08X, Write: 0x%02X, Read: 0x%02X\r\n", &SRAM_START_ADDRESS + i, wr8, rd8);

}

// Test some 16-bit write and reads

for (i = 0x10; i < 0x1F; i+=2) {

  // Write a word

  *(volatile uint16_t *)(&SRAM_START_ADDRESS + i) = wr16;

  // Read a word

  rd16 = 0;

  rd16 = (*(volatile uint16_t *)(&SRAM_START_ADDRESS + i));

  printf("Addr: 0x%08X, Write: 0x%04X, Read: 0x%04X\r\n", &SRAM_START_ADDRESS + i, wr16, rd16);

}

// Test some 32-bit write and reads

for (i = 0x20; i < 0x2F; i+=4) {

  // Write a dword

  *(volatile uint32_t *)(&SRAM_START_ADDRESS + i) = wr32;

  // Read a dword

  rd32 = 0;

  rd32 = (*(volatile uint32_t *)(&SRAM_START_ADDRESS + i));

  printf("Addr: 0x%08X, Write: 0x%08X, Read: 0x%08X\r\n", &SRAM_START_ADDRESS + i, wr32, rd32);

}

My output from IAR Terminal is:

Addr: 0x60000000, Write: 0x88, Read: 0x88

Addr: 0x60000001, Write: 0x88, Read: 0x88

Addr: 0x60000002, Write: 0x88, Read: 0x88

Addr: 0x60000003, Write: 0x88, Read: 0x88

Addr: 0x60000004, Write: 0x88, Read: 0x88

Addr: 0x60000005, Write: 0x88, Read: 0x88

Addr: 0x60000006, Write: 0x88, Read: 0x88

Addr: 0x60000007, Write: 0x88, Read: 0x88

Addr: 0x60000008, Write: 0x88, Read: 0x88

Addr: 0x60000009, Write: 0x88, Read: 0x88

Addr: 0x6000000A, Write: 0x88, Read: 0x88

Addr: 0x6000000B, Write: 0x88, Read: 0x88

Addr: 0x6000000C, Write: 0x88, Read: 0x88

Addr: 0x6000000D, Write: 0x88, Read: 0x88

Addr: 0x6000000E, Write: 0x88, Read: 0x88

Addr: 0x60000010, Write: 0x99AA, Read: 0x99AA

Addr: 0x60000012, Write: 0x99AA, Read: 0x99AA

Addr: 0x60000014, Write: 0x99AA, Read: 0x99AA

Addr: 0x60000016, Write: 0x99AA, Read: 0x99AA

Addr: 0x60000018, Write: 0x99AA, Read: 0x99AA

Addr: 0x6000001A, Write: 0x99AA, Read: 0x99AA

Addr: 0x6000001C, Write: 0x99AA, Read: 0x99AA

Addr: 0x6000001E, Write: 0x99AA, Read: 0x99AA

Addr: 0x60000020, Write: 0xBBCCDDEE, Read: 0xBBCCDDEE

Addr: 0x60000024, Write: 0xBBCCDDEE, Read: 0xBBCCDDEE

Addr: 0x60000028, Write: 0xBBCCDDEE, Read: 0xBBCCDDEE

Addr: 0x6000002C, Write: 0xBBCCDDEE, Read: 0xBBCCDDEE

[michaelhuslig]

I think using FB_AD0 is definitely the problem.  Aligned 16 and 32 bit writes and reads appear ok because FB_AD0 will be 0.  To see the problem with 8-bit writes, you have to write different data to each byte.  I am suspecting that if you configure the FB_AD0 pin to be a GP output, your byte writes will begin working at odd addresses, but you will only be using half of your SRAM.  Rewiring the AD0 pin of the SRAM to the next highest unused FB_ADn pin should give you full access to the SRAM.

[michaelhuslig]

Maybe I can be a little clearer.  Consider the following declared at the start of the SRAM.

uint8_t array[4];

uint32_t dword;

array[0]='A';    //stores in the lower byte of SRAM word 0;

array[1]='B';    //stores in upper byte of SRAM word 1;

array[2]='C';    //stores in lower byte of SRAM word 2;

array[3]='D';    //stores in upper byte of SRAM word 3;

dword=0x01234567;   //stores 16 bits in SRAM word 4 and 16 bits in SRAM word 6;

You are only using half the SRAM.  However if you don't need the full space of the SRAM, you can leave it as is.  Any writes you do to SRAM, you will still be able to read.  The only problem would be if you do something like:

union

{

uint8_t array[4];

uint32_t dword;

}

[Hui_Ma]

Hi Michael,

I think your Flexbus connection is correct.

Please check your Flexbus configuration, the FB_CSCR0[PS] bits should select the 16-bit port size.

For Kinetis Flexbus original from ColdFire Flexbus module, I attached ColdFire Flexbus connection for your reference:

Wish it helps.

Have a great day,
Ma Hui

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[DavidS]

Hi Michael,

The AN4393 is using the FlexBus in a method to use 8-bit Data interface from Kinetis to a 16-bit interface on the MRAM.  Therefore they are not using the A0 for normal SRAM interface implementation and also not using Byte Strobes (FB_BEn).

For the second FlexBus interface in the AN4393 to an LCD, they are not using the A0 because they will always pass 16-bit information to the LCD and not bytes or misaligned longwords.

EDITed/Updated:

For your SRAM FlexBus interface you want to use FB_AD1 to the SRAM A0.

This is becasue the Cypress SRAM is a 16-bit/word addressable memory and the FB_AD0 is not needed.  The FB_BEn signals will let the SRAM know which byte lane to write or read for byte access and both will be enabled for word access.

Regards,

David