Hi
I am in charge of setting up a production test / programming infrastructure for a CSR1012 based design. The tool has to trim the crystal and program the final firmware with adjusted crystal trim and unique bluetooth address for every device.
I am working with the uEnergyTest.dll. I do everything as pointed out in the help for the uEnergyTest. I can trim the crystal, set values and bluetooth address and program the device without error. But the final device does not run (does not start BT broadcast). Programming the same firmware with CsKey entered manually over xIDE it works fine.
As I have an image with OTA enabled, my guess is that this is the source of the problem. A short test with a non OTA image seemed to work fine.
I tried to implement the CsCacheOtaApp switching, but I can't get it to work. The CsCacheOtaApp always gives me an error. The same happens if I use the uEnergyTest application on my PC.
Setting Source to "File", CS Source File to my application image with combined ota/app and in "Use OTA Update Application CS" I set "CSR OTA Update Version" to 7, I get
CSR101x (Hardware ID 0x412B)
Do you report here two problems or one ?
OTP error has noting with crystal trimming…
Anyway, if you code does not run after you run your code(that uses uEnergyTest.dll) it probably a bug in your code.
Try to use a ready application to change the crystal trimming and not your build exe.
Flashing manually through the xIDE is 100% using command-line tools such as e2cmd. You can execute the same set of steps as the xIDE within your production tool to automate the process. The xIDE build output lists every command-line it executes you can just copy and paste into a batch file or create a proc wrapper in your production build tool. I've never programmed a fresh CSR chip using 'uEnergyTest.dll' so I can't comment on your specific issue.
It is one problem. I just tried several things to cope with it.
I know about the programming via command line. The pttest workflow would just be great and easy. It allows trimming, setting of BT address and programming all with the same dll in the same workflow in less the 10 seconds per device!
I did some more tests and can now definitely confirm:
- Applications with no OTA image (just plain appliaction) do work with my test software
- As soon as I have an image with OTA, just changing the config values (as done with a simple app) does not work.
This boils down to the original problem: How to modify csconfig on an image with OTA using the pttest dll. This would be the same as using the uEnergyTest GUI application with the settings from my original post.
Best regards,
Alex
Sounds like whatever the software is doing does not rehash the CRCs properly. You could try doing it yourself if that is the case.
Interesting... Where do I find information about how the image is hash stamped. CSR is keeping back on documentation ;-)
Based on the last post, I did some tests.
My original application flow, which is based on the example provieded in the help to dll function uetCsCacheOtauApp, I do
1. read cs cache from image file (OTA image)
2. calibrate crystal
3. write the value to the cs cache (write item)
4. switch to cs cache ota (this will fail with the checksum error)....
Now, based on the above input, I omitted step 3. (write item), now step 4. is successfull. From this I conclude, that the above step 3. modifies the internal cache, but does not rebuild any hashes/checksum, ....
There is no function to compute hashes or so, I have no idea how to rehash or how to fix that.
Or should I file a bug report? where?
Alex
In the OTAU demo there is /otau_demo/source/ImageCRC.cpp and ImageCRC.h but it is mostly strewn about in bits and pieces, so I have pulled some of it together into this file, hopefully it is slightly helpful, consider it as pseudo-code
https://dl.dropboxusercontent.com/u/58808849/crc.c
also check out the header files /tools/lib/CSR101x_A05/memory.h and /tools/lib/otau/csr_ota.h
Hi Robert,
Thank you for sharing the code for CRC.
Did you test it and see tha img file with changes had been recognized a valid img and run OK ?
No I have not tested it yet, that is why please treat it as pseudo-code. I may test it in the future. If it ever does work, the C code builds on CSR sdk, so in theory you can for example edit the config store directly from within the executing firmware and then write the updated hash and reboot, allowing interesting action such as dynamically changing the BD_ADDR.
There's a crc.c file in C:\CSR_uEnergy_SDK-2.6.0.10\apps\otau_bootloader which is used by the OTA bootloader.
Regarding OTA,
Please note that the OTA the new img upload expect the NVM structure be the same NVM store exactly as the old img.
If you add variable to the new IMG NVM, and location of all NVM variables moved, most likely you will get a wired beehives as rebooting and freezing.
Since the bootloader was design to host multi img in one OTA, and because of the CSR1010 limited ram. It seems not possible to host multi img.
I offer to add a new kind OTA. Without the problematic double booting.
As added service to the normal CSR1010 Firmware.
It will gets data over GATT and store it in the flash directly. No bootloader, no double booting.
If someone is accepting the challenges for the CSR1010 developers, please call my Skype: nissim.test and I will support and supply source code to write img files to flash fast.
The otau bootloader firmware application as far as I know does not rehash the csconfig and control CRCs, though it may verify one or both of them. Historically the otau client application rehashes the crc. I wrote my crc code based on the otau client in October 2015 before CSR opened the source to the otau bootloader firmware application, and I ported it to build on the csr sdk. I already had to reinvent the wheel by the time the source code for it was released, so I've never looked at the source code for the otau bootloader firmware code. I'm sure something in there can be helpful to debug your failing custom production app on the client side for automation of flashing. I'm glad both files are named crc.c that is so interesting.
I've tested erasing all of the flash while in an executing image, including the nvm store. It does not cause freezing or forced reboot. If there is not enough room in flash to write another entire image it is possible to completely replace it without having to boot into a separate image.
Thank you for all your replies. All that CRC stuff and how to do it, doesn't help me with my problem. The uEnergyTest dll does handle everything internally, and given my current knowledge it does it wrong. There is no documented way to access that cache with image and csconfig keys created by the dll.
As a summary:
1. The entire procedure works with non OTA images
2. For OTA images, procedure implemented according to help fails with that CRC check
3. Changing to application csconfig on OTA images before writing anything into the bootloader csconfig works
4. The problem is fully reproduicible with the GUI application delivered with the uEnergyTools
I will try to file a bug report, but I do not expect anything to get fixed. CSR should release the source code of that uEnergyTest dll. I don't understand why they keep that stuff secret and protected. It is no rocket sience and can soloely used for CSR chip sets. So why not make our live easier and the chip more attractive.
For me the "workaround" is not to use OTA (not required in final product, just a nice feature for development). The mid-term solution probably will be to drop CSR entirely from the design. There are other devices with the same or even better performance available.
Thanks for all your help guys
Alex
I believe the "rehash " as to be CSR1010 code, so you can change any CsConfig from running code and store in flash and "rehash " img in flash, so it can boot again with new CsConfig setting.
In this way we do not need NVM store any more. Since all constant variables address in flash can be address, changed, and "rehash
raimondi,
Note that with CSR's tools you can't update the bootloader, only the application. Once you do a manual flash of bootloader + application you can never update 'bootloader + application' or 'bootloader', only 'application'. Are you trying to update the bootloader or the application? Why are you trying to update the csconfig of the bootloader, it is meant to never be changed?
Sorry if I couldn't help ... CSR101x is the lowest power consumption on the market not the highest performance.
Hi
CodeJingle, thanks for your consideration.
I try to do initial programming (first time after production, into an empty eeprom!).
I wanna download a combinde App + OTA image. CSR tools support that. I can do it over xIDE and judging by the options offered by uEnergyTest, it should be supported there.
I implement a production test, where I have to set crystal trim and unique BT address on each device.
CodeJingle,
The OTA always boot after download new img. The new img is download to ram, verified to be CRC OK, and copy on to the EERPOM . Than a fresh boot is done to run the new img. To boot is must since during download the new img the CsConfig is the bootloader CsConfig and not the application. After the boot the app img is load with the app CsConfig.
Note that CsConfig is part of the img, therefor need CRC.
NVM is not part of the img and not part of the CRC, therefor it do not load from new img.
You can call my Skype nissim.test
Raimondi,
You do not need to do crystal calibration per PCB. Since all crystals from same SMD reel will be the same drift. Just do one per production, assuming it’s the same crystals reels.
Update the *.keyr with the crystal good value. And use e2cmd.exe to flash the *.img in all PCBs on the same panel.
Please call my Skype nissim.test if my guide is not clear.