Saving to NVM on STUSB4500 using STSW-STUSB003

Forum|Forum|7 years ago
March 8, 2019
9 replies
2470 views

I am porting the STSW-STUSB003 to my STM32 project that uses a different MCU than the NUCLEO-F072RB. Though it wouldn't matter, I need the functionality in our MCU for production, not an external Nucleo dev board.

I can make changes in RAM, but cannot save to NVM. I'm trying to write to NVM simply using `nvm_flash(Usb_Port);`, but the program hangs.

Using STUSB4500_GUI_v1.0.7, I make the changes and save the NVM configuration and paste that into STUSB_NVM.h.

Since the main.c code doesn't use nvm_flash and the github code has a typo in #include "USB_PD_defines_STUSB-GEN1.h", I suspect this code isn't actually tested and working.

Can anyone confirm getting NVM writes working with the STUSB4500 using the STSW-STUSB003 library?

Should it be as straightforward as saving the NVM_config_STUSB45.h from GUI 1.07 and then in main a simple `nvm_flash(Usb_Port);`? I don't really understand how/why FTP_CUST_PASSWORD (which should be the password, right?) is listed as a register definition set to 0x47. There is a Buffer[10] for a defined value of 0x47? What am I missing here? Is there some app note that explains all this password protection that I missed?

Lastly, the function CUST_ExitTestMode with the word "test" implies changes are not intended to be saved to nvm, whereas this functionality to me, would specifically NOT be for testing and would be for production. Shouldn't this be called CUST_ExitWriteMode?

Thanks in advance

This topic has been closed for replies.

MRexAuthor

Associate III

A bit more info before I'm done for the night. When trying to nvm_flash, it's getting stuck in the CUST_EnterWriteMode function, in the following while loop:

Buffer[0]=FTP_CUST_PWR | FTP_CUST_RST_N | FTP_CUST_REQ ; 
I2C_Write_USB_PD(Port,FTP_CTRL_0,Buffer,1); /* Load Write SER Opcode */
	do 
	{
	I2C_Read_USB_PD(Port,FTP_CTRL_0,Buffer,1); /* Wait for execution */
	}
	while(Buffer[0] & FTP_CUST_REQ);

That's an undocumented register, so I'm stuck. Looks like I'm getting a value of 0xD0 instead of 0x10.

TimKrewSE

Visitor II

Regarding your question concerning the password:

Before you can change anything in the nvm you have to unlock it via writing the password 0x47 into the password register 0x95. The preallocated buffer of 10 Bytes is nonsense in my opinion, as there is only read or written 1 Byte in the whole CUST_EnterWriteMode function.

As you already said the code is fairly messy and not revised for production.

I haven't tested the code on a STM controller but I've ported the code to python so I can test the STUSB4500 IC via the I2C interface on a RaspberryPI, over which I can read and write the nvm.

MRexAuthor

Associate III

Tim,

Thanks for your reply. Since you successfully ported over their CUST_EnterWriteMode function successfully, did you have to change what was being loaded into the registers or the order in which you did things?

Their code has 0x47 being loaded in as first step, so I am expecting the unlock to occur. But it doesn't get through the rest of the function, so I'm thinking the order is wrong, or what is going into the FTP_CTRL_0 and FTP_CTRL_1 registers is incorrect.

I take it you are operating your I2C I/O on 3.3V and don't need a level shifter to 1.8V to use external I2C?

But it would really help me to know if you had to change the contents or order to get NVM writes to work in python, or you simply translated C++ to python with same values, etc.

Thanks and have a great weekend!

timkruse

Visitor II

As I ported it line by line, I did not change anything. Your assumption is also right, that I am interfacing the STUSB4500 chip on a 3V3 logic level, while powering the chip's internals via the VSYS pin also with 3V3.

The NVM is shadowed by the I2C registers 0xC0 to 0xE7 which are all 0x00 if the NVM is locked (Register 0x95 != 0x47). You can verify if the unlocking was successfully with reading one of these registers after loading the password into the password register.

Register 0xE7 for example contains 0xFB as factory default.

MRexAuthor

Associate III

Just to close this thread, my problem was related to I2C configuration/differences and porting the NVM library to our existing STM project. The functions from USB_PD_core.c were working, so I didn't realize the I2C wasn't working for the functions in USBPD_CUST_NVM_API.c (found with logic analyzer). I didn't get to the bottom of that issue, but I was able to get the NVM functions working from our code and confirm the functions as provided work, so long as your I2C stuff is working properly.

Thanks!