EBU App to configure different memory types

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
Dear Infineon Engineers,

please can you tell me, when the app, to configure the EBU for different memory types, will be available.
At the moment its only usabe to setup SDRAM, as I know.

I need to configure a multi-memory system containing 4 different areas:
- SDRAM as external RAM
- NOR Flash to extend the program flash
- NAND flash to use a file system
- external parallel accessible peripheral device to generate an additional USB port

The detailed information I will post in another thread.

Thank you in advance
MJW
0 Likes
8 Replies
Not applicable
Dear Infineon Engineers,

the following configuration is planned:

SDRAM
Option 1: 8 MByte / 64 MBit IS42S16400F
Option 2: 16 MByte / 128 MBit IS42S16800F

Programm Flash (NOR Flash)
32 MByte / 256 MBit S29GL256S

Data Flash for Filesystem (NAND Flash)
256 MByte / 2 GBit S34ML02G1

Additional I want to add an external peripheral chip with parallel interface to generate an additional USB port.

Comment: The Ethernet should be used with the RMII connection to the PHY-Interface.

Would it be possible that someone checks the needed pinout and if there are serious port pin conflicts.
Also, if you have suggestions for alternative components, please can you write it?
We want to get as much memory space as possible...


Thank you and kind regards
MJW
0 Likes
Not applicable
Hi MJW,

1) Currently there is no plan to extend the EBU App support to other memory types, you need to modify by yourself.

2) XMC4500 supports 4 memory regions. Each region can be configured individually to accommodate different types of external devices. You can refer to Table 14-8 (Address Regions) of "xmc4500_rm_v1.5_2014_07" to check whether it fits your application.

4) As for the Ethernet, the ETH core supports IEEE 802.3-compliant RMII/MII (default) interface to communicate with an external Fast Ethernet PHY. Details can be found in Chapter 15.1.1 (ETH Core Features) of "xmc4500_rm_v1.5_2014_07".

4) As for the pins, there are some share pins between EBU and ETH. Pls check according to Table 25-12 (Port I/O Functions) of "xmc4500_rm_v1.5_2014_07".

Best regards,
Sophia
0 Likes
Not applicable
Another Question came up:

Using the Output Multiplexer of the Ports we can select the Signalsource for the Output.Beyond other the two „hardware controlled“ sources (HWO0, HWO1) (look Reference Manual Page 2560). Setup via the Register HWSEL (Reference Manual page 2584).
You can select either HW0 or HW1.

Wir use on Port 5.5 on time the Option HWO0 -> EBU.CAS (for the SDRAM) and on the other Hand the Option HWO1->EBU.A22 (for the NOR Flash)
Looks like we have to set the Register HWSEL regarding of the active CS Signal.

Same seams to be at Port 6.4 (HWO0 -> EBU.SDCKO (for SDRAM), HWO1->EBU.A19 (for the NOR Flash).

So as I understand we canot use the demultiplexten Ports A19-A23 in SDRAM applications and we have to add an external address latch for the NOR Flash, which would be very bad.

Am I right, or did I oversee something.?
0 Likes
TomTom
Employee
Employee
Hello MJW,

I see that you have analyzed some of the limits with HW0 and HW1 port overlaps with your configuration. I would confirm that there will be external HW needed if you want to operate these large external flash memories concurrently with SDRAM.

There is also some extra effort with the NAND type you want to use. This is because unmanaged NAND flash needs a SW driver to handle ECC. Unfortunately SDMMC is not an alternative because it is in conflict with EBU. But there are some managed NAND flash devices which might be an option?

May I ask for your requirements on data transfer rate? The EBU traffic will internally be bundled on the ARM system bus (data and program). That means for best performance EBU should avoid to mix data and concurrent program access thru EBU. Will SDRAM be used for data storage only?

Regards,
Thomas
0 Likes
Not applicable
Thank you Thomas,
one question to the HW select Registers.
0b00 SW
0b01 HW0
0b10 HW1
0b11 reserved
The setting 0b11 in my opinion would be that either HW0 and HW1 could take control over the pin. The HW control is only active, if needed, so in theory it could be possible to select both because there should not happen an overlap. Or am I wrong?

Your question to the performance and usage I will check today and give you the answer.

Kind regards
Johannes
0 Likes
Not applicable
The reason for the SDRAM is the need for big buffers in different communication Systems. The alternative would be SRAM, which costs much more and we wanted to avoid this expensive solution.

Kind regads,
Johannes
0 Likes
Not applicable
MJW wrote:
Thank you Thomas,
one question to the HW select Registers.
0b00 SW
0b01 HW0
0b10 HW1
0b11 reserved
The setting 0b11 in my opinion would be that either HW0 and HW1 could take control over the pin. The HW control is only active, if needed, so in theory it could be possible to select both because there should not happen an overlap. Or am I wrong?

Your question to the performance and usage I will check today and give you the answer.

Kind regards
Johannes


Hi Johannes,

Sorry, your interpretation is not correct. The direct HW control function is to take control over the GPIO or other alternate functions. There is only one type of HW control can be selected at a time.

Best regards,
Sophia
0 Likes
Not applicable
Thank you Sophia,

I understood, that you switch a multiplexer.
At the end, we got no solution for Integration of the SDRAM together with the other Memory types. So now we use an SRAM.

Best regards
Johannes
0 Likes