Hi everyone,
we have just finished the first prototypes of our device and are ready to switch from the daughterboard to our own hardware. Unfortunateley, we are running into issues when it comes to programming the external flash. Using the SmartSnippets Toolbox, we can connect to the device via QSPI, but we can't read data from the flash or write to it.
We can't read the partition table.
The hardware is the same as in the starter kit, except that the flash is for 3V supply instead of 1.8V.
The QSPI VDD IO is supplied with 3.3V, and the jumper for the voltage selection has been set for 3 V.
Do you have any pointers what we could be doing wrong?
Thanks!
冈瑟
Keywords:
Device:
Hi ghschwab,
我增刊ose that its a 681, so what kind of flash is attached ? I suppose that its not like the one used by default in the SDK since all three of theam are 1.8V ? Since you use a Quad SPI flash that is not supported from the SDK you will need to implement the drivers of that particular flash according to the readme file in the sdk/memory/readme.md file. After that you will need to add the new driver in the uartboot.bin (the uartboot.bin operates in automode) rebuild the cli_programmer (which will rebuild the uartboot.bin and include the uartboot.bin in the cli_programmer). After that you will need to replace the default uartboot.bin file in the SS Toolbox (so you will have to take the uartboot.bin file that implements the new flash driver and paste it to the \DiaSemi\SmartSnippetsStudio\Toolbox\common_resources). Regarding the fact that you are not able to read the partition table (i suppose that you are trying to do that via Smart Snippets Toolbox) what kind of error the Smart Snippets promts ? If the flash is empty, there will be no partition to read since the fw generates the partition table as soon as the SDK starts up. The V33 is always on, so there is no need for special handling in order to be enabled.
Thanks MT_dialog
Thank you for your response! It is a 681, and the flash we are using is a W25Q80DV, so very similar to the supported type, except that flash device type is different (0x40 instead of 0x60). I have added a new, modified header file in the memory/include section of my project. Do I also need to do this in the uartboot project? I have tried doing this and changed the dg_configFLASH_DEVICE_TYPE setting and the dg_configFLASH_HEADER_FILE to the new flash, AUTO_DETECT is 0. I rebuilt the uartboot project, the libprogrammer project, and then the cli_programmer project. After that, I copied the uartboot.bin file from the release folder of the uartboot project to the common_resources folder of the SS Toolbox.
It has not caused any changes, it acts like I can read from the QSPI memory, but everything reads 0. When tryint to program, I get the following error message:
[INFO QSPI Flash @18-02-28 09:29:47] Verify writing to qspi address 0x0 failed. Retrying ...
I have also tried setting AUTO_DETECT to 1, unfortunately no difference.
I have noticed that the timestamp on the uartboot.bin file is from the time the uartboot project was built, it does not change after building cli_programmer.
Thanks for your help!
Hi ghschwab,
Yes, you will have to add the support of the new flash in the uartboot.bin file. The uartboot.bin file is the only file that supports the automatic mode dgconfigFLASH_AUTODETECT, and you should leave it this way. The uartboot.bin is the file that will be downloaded into the sysram of the 681 and will communicate with the cli_programmer in order to interact with the flash. So after you have attached the new flash in the SDK (place the new include header file under the other flash header files in the qspi_automode.c under the condition #if FLASH_AUTODETECT == 1 and then you should add the &flash_custom_config in the flash_config_table). By using the above configurations (defining dg_configFLASH_DEVICE_TYPE etc) the uartboot.bin will be able to interact only with the defined flash. The configurations that you have mentioned should be applied only to your project. Re - building the cli - programmer should build the uartboot.bin, if you delete the generated folders from the uartboot project or change a project configuration, they should be re-created when building the cli_programmer and you should see the timestamp changing. In the case of the SS tool and interacting with the flash what you need is a uartboot.bin file that has your flash, the project will go through the available flash drivers and interact with your flash properly (also the flash that you are using looks quite the same with the default). Have you tried using the scripts in order to interact with the flash and check if you are able to download fw ? There is an issue with the SS toolbox and operates the flash in quad mode, if the flash is new and the QE bit is not set then SS will not be able to interact with the flash, try to operate the flash with the scripts (the QE bit then should then be set and you will be able to interact with Smart Snippets as well). The V33 is always active on the device so there is no need to for additional sw configuration.
Thanks MT_dialog
Thank you for your answer!
After deleting the uartboot.bin file, it is recreated when the cli_programmer project is built.
Copying the file to the common_resources folder and using the SS tool has not relolved the issue however. I have tried using the scripts from within Smart Snippets Studio (Link on the menu bar), but that also hasn't worked. Should the scripts be executed directly under Windows, at the command line? I have tried this also, but with no success. What would be the procedure for this?
Thank you,
冈瑟
Hi ghscwab,
是的,如果你有一个工作委员会,有效flash drivers for your flash, then for burning the flash you can run either directly run the scripts from the menu bar as the documentation indicates, or you can run the cli_programmer using the CLI interface (which is what the scripts automate the cli procedure and invoke the cli programmer). You will also find documentation on how to burn the flash i the UM-B-047 Getting Started.pdf and also you will be able to find a CLI guide in the UM-B-044 Software Platform Reference.pdf on Appendix B.
Thanks MT_dialog