K20 external memory interface description wanted.

[Tbspd_TOK]

I'm in th eprocess of designing in the K20 as a replacement for an ST MCU.

I'm on the lookout for a detailed description / app.note for interfacing an external SRAM to the K20. I want to use a 16bit non multiplexed configuration. I'm looking for both hardware description and the setup of the necessary registers.

Does anybody sit on this type of information, and care to share?

TOK

[dmarks_ls]

You don't mention what package of K20 you intend to use; that plays a large role in figuring out what pins are available and what functions overlap.  You need to be looking at the reference manual for the specific subfamily (pin count) of K20 you will be using; that will lay out what pins are available.  (Just the pin muxing table by itself is also available in the subfamily datasheet.)

(BTW folks, I'm figuring this stuff out for myself as well.  If I've got something wrong here, PLEASE reply and correct me, thanks.)

I'm currently doing a design on a 144-pin K60 with a non-multiplexed 8-bit data, 16-bit address bus.  Now, when you read the FlexBus section in the manual, understand that it's the same generic section that's pasted into all Kinetis reference manuals for parts that support FlexBus.  So it's going to talk about multiplexed and non-multiplexed, FB_A, FB_D, and FB_AD lines.  The pin multiplexing section of your manual describes what pin functions are actually available.  And on my 144-pin K60, I only have FB_AD[31:0] and FB_A[24:29] available.  So you're maybe thinking "crap, I have to do a multiplexed design".  Actually, no.

From what I can tell, there's no configuration option in the FlexBus control registers for non-multiplexed versus multiplexed bus access.  The bus timings are going to be exactly the same, regardless of how you have your device physically attached to the Kinetis.  All that matters is which pinmux functions you enable and how you attach your device to the Kinetis.  When doing an 8-bit or 16-bit bus, FlexBus will assert data on FB_AD[31:24] or FB_AD[31:16] respectively.

So you're doing a 16-bit part.  If you only need a 16-bit (64K) address space, then you attach your address bus to FB_AD[15:0], your data bus to FB_AD[31:16], set the BLS (byte lane shift) bit to 0, and there you go.

Looking at the K20 datasheets, it appears that if you want a non-muxed 16-bit interface, you will need at minimum a 121-pin device; the 100-pin device does not have all of the FB_AD signals available.  If you need to keep your pin count low, you can do a muxed 16-bit data, 20-bit address bus on the 80/81-pin part; you'll just need a 16-bit address latch.

[Tbspd_TOK]

Hi drodgers,

Thanks for the information. I'm using a 144pin part and after reading your post, I found how to decode the pin assignment table. As far as I can see the FB_A port is available up to FB_A23(FB_AD[15:0] and FB_A[23:16]), for a 16bit non multiplexed design.

The main problem now, is to solve the I/O puzzle to get all the functions I need wired out of the chip.

I'm really missing a configuration tool/program here, but none is available for this chip. (MK20FN1M0VLQ12)

Thanks again.

[OliverSedlacek]

Just to let you know, I'm trying this out and I've got the SRAM nBHE and nBLE swapped around. It seems obvious now, but FB_BE31-24 must drive the SRAM nBHE and FB_BE23-16 must drive the SRAM nBLE when BLS is 0.

[dmarks_ls]

---

Oliver Sedlacek wrote:

Just to let you know, I'm trying this out and I've got the SRAM nBHE and nBLE swapped around. It seems obvious now, but FB_BE31-24 must drive the SRAM nBHE and FB_BE23-16 must drive the SRAM nBLE when BLS is 0.

---

Correct, you don't flip the endianness of the bus, you just shift it, so 31-24 is still MSB (H) and 23-16 is LSB (L).

---

iafg wrote:

Did I miss something?

Freescale provides a pinmux tool here

http://www.freescale.com/solutionadvisor

The memory bus interface lets you select both the data width you want and the address width.

(the first time I used it clarified that you can have non-multiplexed 16 bit data and >16bit address..just a little misconception I had that it was ONLY a 32bit wide bus. But actually there are extra address lines available on other pins.)

---

Yeah, I'm not a huge fan of the Solution Advisor strictly as a pinmux tool, in that it doesn't let you do the pinmuxing yourself.  I think TI has a much better pinmux tool for some of their parts (my specific experience is the OMAP-L137); it lets you check off specific peripherals you want, gives you a big scrollable list of pins and functions, ans lets you activate/deactivate specific pins.  i have to do that on paper with highlighters for the Kinetis parts.

[dmarks_ls]

iafg wrote:

Did I miss something?

Freescale provides a pinmux tool here

http://www.freescale.com/solutionadvisor

The memory bus interface lets you select both the data width you want and the address width.

(the first time I used it clarified that you can have non-multiplexed 16 bit data and >16bit address..just a little misconception I had that it was ONLY a 32bit wide bus. But actually there are extra address lines available on other pins.)

[jimtrudeau]

Solution Advisor really tests the peripherals you've selected to see if there's a conflict. So not really a pin muxing TOOL per se. If you are not familiar with Processor Expert, that is (among many other capabilities) Freescale's tool for pin muxing. It is available inside CodeWarrior, and as a stand alone Eclipse pluging, so you dont' have to use the CodeWarrior tools. 

[OliverSedlacek]

We are using IAR for our project, so we haven't looked at Codewarrior or Eclipse based solutions. Configuring the chip manually sure is tedious, and we've just spotted a mistake we made. Most of the pins need to be muxed to ALT5 for Flexbus functionality, but PTD8 to PTD15 need to be set to ALT6 to get Flexbus address lines A16 to A23. Ho hum.

[iafg]

Did I miss something?

Freescale provides a pinmux tool here

http://www.freescale.com/solutionadvisor

The memory bus interface lets you select both the data width you want and the address width.

(the first time I used it clarified that you can have non-multiplexed 16 bit data and >16bit address..just a little misconception I had that it was ONLY a 32bit wide bus. But actually there are extra address lines available on other pins.)

[dmarks_ls · Accepted solution]

Correct, you use FB_AD[31:16] as your data bus, and then use FB_A[23:16] and FB_AD[15:0] as your 24-bit address bus.  ALE is muxed on CS1, but since you're not multiplexing, you don't need that.  There are byte lane selects and other functions (e.g. external acknowledge) muxed on some of the other chip selects; you'll have to figure out how to connect those for your design.

You're right, a pin selection tool is severely lacking here; I think a good example of how to write one is TI's pinmux utility for the OMAP series of processors (my specific experience was with the OMAP-L137).  Lets you select specific modules, and then select or deselect specific pins, and show you a whole highlighted list of what's selected and what conflicts exist.  Freescale has some catching up to do in this regard.  The "part selector" online utility just is not the same, very clumsy to use.

EDIT: Just checked, FB_A[29:24] is also available on PTA24-29.  So you have up to a 512MWord 16-bit address space if you want.

[Tbspd_TOK]

I'm good with 2Mb, so FB_A19 is the msb here. Even so, I may need to go for a multiplexed design due to the I/O config, we'll see.

I've used the CAPS program from STM for the STR91x range of processors. A very good configuration solution. A pity the STM don't have a defined long life time for their processors. We found out too late that the one we use, has a limited life time. That's the reason we're converting to the K20.