Data Duplicates in EBU region after offset of 0x2000

[Qu19_4750531]

Dear Infineon Team or Jesus,

Please can anyone help me with below query ?

I am working on EBU region CS1. When I perform a write on memory location say 0x64000000, i see data is duplicated at location 0x64002000. This is true for any location.
I am writing 0x0102 at base address and I see same data duplicated after offset of 0x2000. Please see attached photos.





Is this expected behaviour ? Or Am I missing any configuration ?
If this is expected then is EBU compatible to interface with external SRAM ?


Below is my configuration-

// Zero the configuration structure before we set anything.
configuration.ebu_clk_config.raw0 = 0U;
configuration.ebu_mode_config.raw0 = 0U;
configuration.ebu_free_pins_to_gpio.raw0 = 0U;

// These values get written to the CLC register.
configuration.ebu_clk_config.ebu_clk_mode = 1U; //Fcpu is selected
configuration.ebu_clk_config.ebu_div2_clk_mode = 0U; //standard clocking mode selected
configuration.ebu_clk_config.ebu_clock_divide_rati o = 3U; //Divide by 4 ; Asynchronous cycle Fcpu/4 is used and Febu is not being used

// These values get written to the MODCON register.
configuration.ebu_mode_config.ebu_sdram_tristate = 1U;
configuration.ebu_mode_config.ebu_extlock = 1U;
configuration.ebu_mode_config.ebu_arbsync = 0U;
configuration.ebu_mode_config.ebu_arbitration_mode = 3U; // Master mode.
configuration.ebu_mode_config.bus_timeout_control = 0U;
configuration.ebu_mode_config.ebu_ale_mode = 0U;

// These values get written to the USERCON register.
configuration.ebu_free_pins_to_gpio.address_pins_g pio = 0x0U;
configuration.ebu_free_pins_to_gpio.adv_pin_gpio = 0U;

ebu_bus_read_config.raw0   =   0x40400000U;  //EBU_REG_BUSRCON0
ebu_bus_read_config.raw1   =   0X32000189U; // EBU_REG_FPGA_BUSRAP0;
ebu_bus_write_config.raw0 =   0x40400000U;	// WRCON
ebu_bus_write_config.raw1 =   0X32002101U;	// WRAPR

XMC_EBU_AddressSelectEnable(XMC_EBU,  1U, EBU_CS1);
XMC_EBU_AddressSelectEnable(XMC_EBU, 2U, EBU_CS1);
XMC_EBU_AddressSelectDisable(XMC_EBU, 4U, EBU_CS1); 

Please can you look into my query and let me know your feedback as i am kind of stuck and cant find anymore information.

Thank you

Regards
Query1920

[Qu19_4750531]

Hello Infineon Team,

Any help on this issue please.
My client is losing interest in XMC4700. I would appreciate if you could provide your feedback on this topic.

Regards
Query1920

[jferreira]

Hi,

I can not see anything wrong in the configuration.

Could you share the pins connections to the SRAM?
Could you attach a logic analyzer to the EBU pins during the SRAM access?

Did you try reading the EBU using the CPU instead of the debugger?

Regards,
Jesus

[Qu19_4750531]

Hi Jesus,

I have multiple devices connected over EBU .. FPGA on CS0, SRAM(CY7C1061G) on CS1 and Flash on CS3.
I have configured AGEN for Demux Asych type and PORTW as 01 for 16 bit non multiplexed. I have attached pin assignment for your reference.


Below is my test code( ram_test2):

static void SRAM_WriteDataBuffer(uint16_t* const writeBuffer, const uint16_t numberOfWrites, uint32_t writeStartAdd)
{
    uint32_t  writeCounter    = 0; 
    
    for(writeCounter = 0; writeCounter < numberOfWrites ; writeCounter++)
    {
        *(volatile uint16_t*)(SRAM_BASE + (writeStartAdd << 1)) = writeBuffer[writeCounter];
        writeStartAdd++;
    }
    
}


/************************************************************************************************
* SRAM_ReadDataBuffer function perform read from SRAM via ebu in buffer
*
*
*************************************************************************************************/ 
static void SRAM_ReadDataBuffer(uint16_t* const readBuffer, const uint16_t numberOfReads,  uint32_t readStartAdd)
{   
    uint32_t readCounter    = 0U; 
    
    for(readCounter=0; readCounter< numberOfReads; readCounter++)
	{
        readBuffer[readCounter] = *(volatile uint16_t*)(SRAM_BASE + (readStartAdd << 1));
        readStartAdd++;
	}
}


void ram_test2(void)
{
    uint16_t wrBuff[10] = {0,1,2,3,4,5,6,7,8,9};
    uint16_t wrBuff1[10] = {1,1,0,0,1,1,0,0,1,1};

    SRAM_WriteDataBuffer(&wrBuff[0],10,0);

    for(uint16_t delay = 0; delay< 500; delay++){}
        
    SRAM_WriteDataBuffer(&wrBuff1[0],10,0x1000);  
        
//    /* Read at location 0x64000000 and 0x64002000 */
    SRAM_ReadDataBuffer(&readBuffer1[0],10,0);
    SRAM_ReadDataBuffer(&readBuffer2[0],10,0x1000);
}

I probed EBU-AD16 and EBU-AD29 below are my observations- ( Please see attachedA14_A2_write_0_2000.psdata)
- AD29 becomes high the moment i enable Region 1 of CS1
- When write happens at 0x0000 location, AD29 goes low, AD16 toggles as expected
- When write happens at 0x2000 location, AD29 goes low and i could see AD16 toggles as expected.


More closer look at AD16


AD29

I am initializing AD29 as
XMC_GPIO_MODE_OUTPUT_PUSH_PULL,
XMC_GPIO_OUTPUT_LEVEL_LOW,
XMC_GPIO_OUTPUT_STRENGTH_STRONG_SHARP_EDGE

I have no clue why AD29 goes high as i enable Region 1. My understanding is it should remain low until and unless that pin is driven by the request.

Please let me know your feedback

Regards
Query1920

[jferreira]

Hi,

I guess you are configuring the HW controlled register for the EBU IOs?
The overshoots in the signal can be maybe overcome with XMC_GPIO_OUTPUT_STRENGTH_STRONG_MEDIUM_EDGE instead of XMC_GPIO_OUTPUT_STRENGTH_STRONG_SHARP_EDGE.

Regards,
Jesus

[Qu19_4750531]

Yes i am initializing hardware control registers for EBU lines via below function.
XMC_GPIO_SetHardwareControl(Px_x, XMC_GPIO_HWCTRL_PERIPHERAL2)

Is it expected to see line AD29 low when we are writing at location 0x64002000 ? In my opinion it should remain high.
Is my understanding correct ?

[jferreira · Accepted solution]

Hi,

I tried on a XMC4700 RelaxKit. Most of the pins are not available, but enough to debug the issue.
Attached is the main.c of my project and in the image the last write and the next two reads are shown.


If you call SRAM_WriteDataBuffer(&wrBuff1[0], 8, 0x1000); you will be start writing at address 0x2000, but AHB[16:1]->AD[31:16] and AHB[24:17]->A[23:16], this means that AD28 will toggle to 1 and not AD29.
If you call SRAM_WriteDataBuffer(&wrBuff1[0], 8, 0x2000); like in the attached code, the AD29 will toggle to 1. As seen in the wr access and in the second read access.

Regards,
Jesus

[Qu19_4750531]

Hi Jesus,

Thank you so much for your feedback. I really appreciate your help.

I realized the addressing this morning and that is the whole reason i left shifted the address offset by 1 in SRAM_WriteDataBuffer() to compensate for internal addressing AHB[16:1].
i once again revisited my configuration and i found that i missed out to configure hardware control register for one of the pin hence it was giving me mirroring value issues.
It works well now.

Thank you so much once again !!

Regards
Query1920