TDA4VM: Warm reset not working with eMMC on custom board

Hi Bart 

Bart Philips said:

We have a custom board based on the SK-TDA4VM board. We have added eMMC (the same as on the EVM board) to the board, but when performing a warm reset either with Linux (reboot) or with u-boot (reset), the board does not boot again. The console output stops at resetting/rebooting. Booting after a power reset is functioning correctly, both when using the eMMC boot and eMMC user boot switch settings.

SK-TDA4VM does not have emmc.

From where you took this schematic reference .

Regards
Diwakar

Hi Diwakar,

We used the schematic reference of the EVM common processor board.

Regards,

Bart

Hi Bart 

Understood so basically you are using TDA4VM soc and taking reference from the CPB 

Have you tried adding logs on the driver shutdown sequence to see where exactly it is failing ?

Regards
Diwakar

Hi Diwakar,

The shutdown sequence seems to be working OK, we see that the RESETSTATz pin pulls the reset signal of the eMMC low after resetting/rebooting (for about 200 microseconds). Also using the XDS110 debug probe I see that the DMSC and MCU R5_0_0 go through a reset and are active after the reset, but are stuck (MCU_R5_0_0  at memory address 0x0000000C and DMSC at memory address 0x0000389C). My guess is that the SOC indeed resets, but the bootloader is not able to read the eMMC correctly.

Regards,

Bart

HI Bart 

I tested on the evm reset is working fine .

Which emmc part you are using is it the same as of evm?

can you share schematic for the emmc connection .

Regards
Diwakar

Hi Diwakar,

We use the same emmc as the evm. The schematic of the EVM connection is as follows:

Kind regards,

Bart

Hi Bart 

Bart Philips said:

We use the same emmc as the evm. The schematic of the EVM connection is as follows:

I will ask hw expert to review this.

In the meantime, can you check what transaction is happening between emmc and ROM using emmc protocol analyzer.

Regards
Diwakar

Hi Diwakar,

We unfortunately do not have the equipment to analyze the eMMC communication lines and the clk line is not easily available for probing. We did check with a scope on the data lines to check if communication is happening and we see that there is communication on the eMMC data lines after the reset (wrt RESETSTAT pin). There was a similar relation between the reset signal and the activity on the eMMC data lines for the hard reset and the soft reset, however, after the first burst of activity on the eMMC interface the communication stops in the soft reset case.

Kind regards,

Bart

Hi Bart 

May be the warm reset on your custom board not keeping the emmc in a proper state and because of which ROM code 

is not able to read the image from emmc .

Are you getting any data signals on the data line after warm reset ?

Regards
Diwakar

Hi Diwakar,

After warm reset we get some signal on the data lines, but after the first burst of data the signal stops, whereas for a cold reset we see that the signal on the data line continues.

Any update from the hw expert?

Kind regards,

Bart

Hi Diwakar,

Just a reminder, was there any update from the hw expert?

Kind regards,

Bart

Hi Bart,

Can you clarify which version of the EVM (common processor board) you got the schematic you attached above from?

Regards,
Matt

Hi Matt,

This is from the EVM PROC079E3D schematic.

Regards,

Bart

Hi Bart,

Thanks for confirming the version of the EVM. I still working with my team to confirm whether or not it is a hardware problem based on your EVM setup. 

Based on discussions with my team, our initial feeling is that hardware is likely fine based on solid functionality with a full PORz. With a "warm reset," software could be making bad assumptions on what should be reinitialized which can lead to reboot issues.

As I keep conferring with my team, I will keep you updated.

Regards,

Matt

Hi Bart,

Can you check the value of EXT_CSD177 when you are at u-boot or kernel prompt? 

Thanks,

Matt

Hi Matt,

Thanks for your follow up. If I interpreted the datasheet of the EMMC correctly, CSD177 should be the boot bus register:

For that "mmc extcsd read /dev/mmcblk0" returns:
Boot bus Conditions [BOOT_BUS_CONDITIONS: 0x02]

I believe I set that following the Application Report TDA4 Flashing Techniques with the command "mmc bootbus 0 2 0 0".

Regards,

Bart

Hi Bart,

EXT_CSD177 should be for BOOT_BUS_WIDTH instead of BOOT_BUS_CONDITIONS. Could you try reading this instead?

Thanks,

Matt

Hi Matt,

I got this from the uboot source code:

* BOOT_BUS_CONDITIONS[177]
* BOOT_MODE[4:3]
* 0x0 : Use SDR + Backward compatible timing in boot operation
* 0x1 : Use SDR + High Speed Timing in boot operation mode
* 0x2 : Use DDR in boot operation
* RESET_BOOT_BUS_CONDITIONS
* 0x0 : Reset bus width to x1, SDR, Backward compatible
* 0x1 : Retain BOOT_BUS_WIDTH and BOOT_MODE
* BOOT_BUS_WIDTH
* 0x0 : x1(sdr) or x4 (ddr) buswidth
* 0x1 : x4(sdr/ddr) buswith
* 0x2 : x8(sdr/ddr) buswith

for the "mmc bootbus dev boot_bus_width reset_boot_bus_width boot_mode" command.

I used the  "mmc bootbus 0 2 0 0" command to set it, so boot_bus_width should be 2.

Regards,

Bart

Hi Bart, 

This makes sense based on the code. However, to confirm whether or not the reset enable could be the issue here, you would need to read back the actual data to verify it. Do you have a means to read these values at a power up time?

Regards,

Matt