eMMC HS200 clarification

[andrelongo85]

Hi there,

we are in the process of developing a product based on the STM32MP151F which will be USB powered (USB 2.0 device).

We are aiming to have it connected to an eMMC for mass storage and we would like to achive the highest R/W speed which should be 200MB/sec using HS200.

1) If my understanding is correct we cannot use the STM32MP157F-EV1 as starting point as the boards is using the STPMIC1A which regulates the eMMC VCCQ @3.3V and it incompatible with HS200, is it correct?

2) Has the STM32MP151 ever been tested at HS200 speed with a commercially available eMMC? Is there e refence design that e can use as starting point?

3) We have read the "2.3.19 DLYB limits SDMMC throughput" errata. Does it implies that HS200 is unusable? Or we can use it and it is just enough to disable the DLYB? If so why should we enable the DLYB in the first time?

4) If we use the STPMIC1B which regulates VDD at 1.8V making it compatible with HS200, is there any drop in the MPU performances?

5) Is there a reference design/app note covering the STM32MPU and STPMIC1 integration on an USB power supply? with 1.8V VDD possibly.

Thanks for your help,

Andrea

[PatrickF · Accepted solution]

Hi @andrelongo85​ 

first of all, Linux system are usually not designed to work as an USB BUS powered device. You will face some issue for USB certification due to power required and time needed until USB enumeration is done.

This is not the case if your product embed a battery charged by USB (there is still some concerns around dead battery, but it is manageable at system level).

Maybe have a look to AN5260 STM32MP151/153/157 MPU lines and STPMIC1 integration on a battery powered application

Regarding your questions, here are some answers:

1) Yes, as per eMMC JEDEC standard, HS200 need 1.8V IOs

2) and 3) STM32MP15 has been tested in HS200 mode, but speed is limited by the IO capabilities at 1.8V (105MHz for eMMC, stated in product datasheet) and the DLYB limitation you mention.

So, to sum-up, as the eMMC is somewhat limited to ~100 MBytes/s raw bandwidth, it is more easy to use 'High speed DDR' than 'HS200' as DDR mode works at 3.3V and requires a slower clock (less power and less noise) while still providing 104MBytes/s raw bandwidth.

4) If you want to use HS200, STPMIC1B is mandatory (or you could change STPMIC1A NVM on first boot as not using HS200 until Linux).

Using 1.8V IO does not make any internal performance difference except that some IOs (e.g. LTDC // for display) will have lower perf.

STPMIC1B is usually a good choice for portable devices (battery powered) as default NVM settings more tailored for low power platform (e.g. LPDDR3 and IOs at 1.8V)

Regards,

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[andrelongo85]

Hi Patrick,

thanks for your precious answer.

regarding the power consumption I have read the appnote:

https://www.st.com/resource/en/application_note/an5284-stm32mp1-series-system-power-consumption-stmicroelectronics.pdf

And STM32MP15x power consumption seems to be far lower than the 2.5W that can be taken form USB 2.0. Why you think we will face some power consumption issue?

Do you know how long will it take for Linux to boot up? If I understand correctly we can enable the USB peripheral also in the first stage bootloader dts (tf-a), could this help to pass successfully the enumeration process?

Cheers,

Andrea

[PatrickF]

Hi @andrelongo85​ 

I think there is some power (5V/100mA ?) as well as timing constrains (e.g. time where pull-up are present to start enumeration, and enumeration end) which make such product not conform to USB standard i.e. not certifiable in this category (but usually work well).

I think even if you could make some tricks inside TF-A (or more likely in uBoot), in a real world, I guess USB is initialized and enumerated by Linux (which come late).

Linux cold boot is quite long (5 seconds sound reachable with some optimizations).

STMicroelectronics does not provide USB Bus Power devices solutions for STM32MP1 products and we do not recommend to go in that direction (does not mean there is no solutions, but it would be your duty to design and test it up to USB product certification).

Note that USB Bus powered device (like mouse, webcam, etc...) is different than USB Battery powered device (portables devices like action-cam, GPS, etc...).

USB Battery powered device is certifiable and used by some STM32MP1 customers.

Regards.