Using SSS v2.0.07
SDK 10.0.4.66
was able to load/compile/modify pxp reporter demo , debug using RAM and get the usb kit doing things.
tried to flash it with the .bin file created. (i.e. run it standalone)...used the cli-programmer and J Link 6.44 GDB (i.e. command prompt style)
didnt do anything (i.e. not running).
went back into sdk to try and debug...
while debugging get all sorts of errors...(see attachments).
re-flashed the usb with the factory fw.bin...the usb runs standalone no problems.
went back to debug the project in SDK via RAM...same errors showing up....?
why?
Questions:
1) did I screw up the memory writing to wrong locations while flashing?...i used the .bin file created in SDK (release build for QSPPI)
2) I see docs on using QSPI flasher SSTB, pretty general...any more detail?....offests, etc...etc...)
3) step by step procedure to build burnable code to upload to device from sdk?
4) UM-B-057, SSS manual, Section 5, Scripts. the download of the SDK 10.0.4.66 has a folder "scripts" but nothing in there (i.e. nothing that windows recognizes ). Where can I get these scripts ?
jwyoungster……任何想法为什么这样?….once i get this going im integrating the da14695 into one of our products...just need to be able to reliably debug and burn fw ....im guessing a user error due to me. hoping for response asap.
thank you!
Hi jwyoungster,
Can you describe how you programmed the bin file, with what commands?
Regarding the scripts you mentioned, there're python scripts files in utilities\scripts\mem_report, which should be listed in windows.
I believe the first thing I did was open up the segger jlink GDB server. then opened up a command window.
copied the .bin file created in the SSS to that binaries folder where the cli-programmer exe resides.
issued the command to upload....it appeared to work...(i.e. file uploaded...feedback from command prompt/gdb looked ok)
reset the usb kit....no advertising from the stick (I modified the advertising name to recognize it easier....it worked fine when I was in debug mode testing the mods I made to the pxp reporter stuff)
then I re-opened the SSS and wnet to debug....which is where you see all the messages crahsing it which I attached ...
Next, using above procedure, uploaded the fw bin factory for that usb kit. Reset the usb stick...advertising as expected with the factory firmware.
Go back into SSS...try to debug using the modified pxp reporter code....get teh massive crashing errors as shown in attachments.
????
Did i screw this thing up to point where it is useless? any way to recover?..
Again, the whole point of this excercise was to insure I could debug, upload and run code...before I start adding stuff to the headers on the usb kit.....
At some point I tried to run SSTB, the QSPI programmer portion...I pointed to the .bin I created...then burned into chip...messages seemed ok..no faults...but when you run usb kit nothing as described above (i.e. no advertising).
in SSTB, pointed to factory firmware bin...burned chip...it worked...
anything to get me by this roadblock would be really helpful..
thank you!
Hi jwyoungster,
To run your code from QSPI, I would suggest to refer "9.3.2 Build the project to run from QSPI Flash" in UM-B-090, in which you can use "DA1469X-00-Debug-QSPI" for building and use "Run > External Tools > program_qspi_jtag" to program QSPI. Then could debug with the config of "QSPI_DA1469x".
ok...
will try that.
I was orgianally debugging from RAM...which worked fine....
Then went to "burn" teh chip so it could run standalone with the code...
after burning, I was not able to debug period...
我会尝试一下,但我确信我将得到的the same results shown in the attachments I sent.
Q: burning chip to run stand alone....procedure?..will the BIN file I create in SSS suffice, or does it need to be messaged before burning?....which build would you use to burn the chip for standalone (QSPI Release?)...not looking to burn it OTP....bascially burn code and then as code matures , upload new code...
If you could answer these questions I'd appreciate it.
willl let you know results of your suggestion
thank you for responding.!
those scripts....
see attached?
how do I get them to be recognized by windows?
using sdk 10.0.4.66
(see attached)