Program QSPI Flash DA1469x USB-Kit

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at https://www.dialog-semiconductor.com/support . We’ll be fixing bugs / optimising the searching and tagging over the coming days.
11 posts / 0 new
Last post
rubicoaxel
Offline
Last seen: 2 years 5 months ago
Joined: 2019-05-30 18:29
Program QSPI Flash DA1469x USB-Kit

Hello!
 

I am a new user trying to familiarize myself with the SmartSnippets development environment. Im using:

Dev-kit:  DA14695-00HQDEVKT-U
SDK: SDK_10.0.4.66.2
JLink: JLink_Linux_V644i_x86_64
SmartSnippets: SmartSnippetsStudio2.0.8

I have successfully compiled the test program "pxp-reporter" and can load it to RAM and debug in SmartSnippets. I can scan the BLE device from my phone so all is well and working so far.

Now I would like to try to flash the "pxp-reporter" to the dev-kit but I cannot get it to work.
I have tried two methods (see below) without result.

General questions:
- I dont understand the flash process itself (whats the purpose of uartboot.bin for instance?). Is this documented somewhere?
- Am I going about this the wrong way? Are there better ways to flash? 

Very thankful for help.

Method1: 
Following: http://lpccs-docs.dialog-semiconductor.com/um-b-090-da1469x_getting_started/07_Your%20First%20DA1469x%20Application%20%E2%80%93%20Advertising%20Demo/Your%20First%20DA1469x%20Application%20%E2%80%93%20Advertising%20Demo.html#build-adv-ble-in-debug-qspi-configuration

Step1: I build the binary with the Debug_QSPI build configuration
Step2: I use run -> external tools -> program_qspi_jtag and get the following output

........................................................................................................................
..
.. PROGRAM QSPI
..
........................................................................................................................
.
........................................................................................................................
..
.. Programming image
..
........................................................................................................................
cli_programmer 1.26
Copyright (c) 2015-2019 Dialog Semiconductor

bootloader file not specified, using internal uartboot.bin

Then it hangs forever

 

Method2: 
Then i try to use command line tools directly inspired by: SDK_10.0.4.66.2/doc/html/cli_programmer.html
I could not find any documentation regarding GDB-server parameters (is there any such doc which I failed to find?) but I took the parameters from SmartSnippets invocation and started gdbserver as below:

GDB-server output:

JLink_Linux_V644i_x86_64//JLinkGDBServer -if swd -device Cortex-M33 -endian little -speed 8000 -port 2331 -swoport 2332 -telnetport 2333 -vd -ir -localhostonly 1 -log jlink.log -singlerun -strict -timeout 0 -nogui -rtos GDBServer/RTOSPlugin_FreeRTOS
SEGGER J-Link GDB Server V6.44i Command Line Version

JLinkARM.dll V6.44i (DLL compiled May 17 2019 17:37:26)

Command line: -if swd -device Cortex-M33 -endian little -speed 8000 -port 2331 -swoport 2332 -telnetport 2333 -vd -ir -localhostonly 1 -log jlink.log -singlerun -strict -timeout 0 -nogui -rtos GDBServer/RTOSPlugin_FreeRTOS
-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      localhost only
Generate logfile:              on
Verify download:               on
Init regs on start:            on
Silent mode:                   off
Single run mode:               on
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 Cortex-M33
Target interface:              SWD
Target interface speed:        8000kHz
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link OB-SAM3U128 V3 compiled Jan  7 2019 14:06:26
Hardware: V3.00
S/N: 483051972
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Received monitor command: clrbp
Received monitor command: reset 0
Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Received monitor command: sleep 10
Sleep 10ms
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x0000076C)
Received monitor command: memU32 0x20010000 = 0xdeadbeef
Writing 0xDEADBEEF @ address 0x20010000
Received monitor command: memU32 0x20010004 = 0xdeadbeef
Writing 0xDEADBEEF @ address 0x20010004
Received monitor command: memU32 0x20010008 = 0xdeadbeef
Writing 0xDEADBEEF @ address 0x20010008
Received monitor command: memU32 0x2001000c = 0xdead10cc
Writing 0xDEAD10CC @ address 0x2001000C
Downloading 4 bytes @ address 0x100C0050 - Verify failed
Received monitor command: sleep 100
Sleep 100ms
Received monitor command: reset 0
Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Received monitor command: sleep 1
Sleep 1ms
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x200010CA)
Downloading 2 bytes @ address 0x50000024 - Verified OK
Received monitor command: loadbin /tmp/cli_programmer_IDqXYy, 0x00000000
Loading binary file [/tmp/cli_programmer_IDqXYy] ...
Downloading 30484 bytes @ address 0x00000000 - Verified OK
Binary file loaded successfully (30484 bytes downloaded)
Received monitor command: reset 0
Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Received monitor command: go
Starting target CPU...
Received monitor command: reset 0
Resets core & peripherals via SYSRESETREQ & VECTRESET bit.
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x0000076C)
Downloading 1 bytes @ address 0x00000218 - Verified OK
Performing single step...
...Target halted (Vector catch, PC = 0x0000076E)
Starting target CPU...

cli_programmer output:

SDK_10.0.4.66.2/binaries$ ./cli_programmer gdbserver 0x0 ../projects/dk_apps/demos/pxp_reporter/DA1469x-00-Debug_QSPI/pxp_reporter.bin 
cli_programmer 1.26
Copyright (c) 2015-2019 Dialog Semiconductor

bootloader file not specified, using internal uartboot.bin

Uploading boot loader/application executable...
Executable uploaded.

Then it hangs forever

 

Device: 
PM_Dialog
Offline
Last seen: 7 months 1 week ago
Staff
Joined: 2018-02-08 11:03
Hi rubicoaxel,

Hi rubicoaxel,

Can you please follow the procedure below and then let me know if you are able to download firmware to QSPI Flash?

  1. Run the program_qspi_config script and select the appropriate configurations. Please refer to  9.4. Configure SmartSnippets™ to write to Flash of the document which have attached.
  2. Run the ersase_qspi_jtag script
  3. The execute the program_qspi_jtag script. Make sure that you have selected the project from the “Project Explorer”

Thanks, PM_Dialog

rubicoaxel
Offline
Last seen: 2 years 5 months ago
Joined: 2019-05-30 18:29
Thank you very much for your

Thank you very much for your quick reply!

I have performed step 1 with parameters:
- Product ID: DA1469x-00
- Flash conf: MX25U3235F
- Active_fw_image_addr: 0x2000
- update_fw_image_address: 0x2000

When runnig erase_qspi_jtag I get the same hang-forever problem as before (pxp_reporter project is selected as you suggest in #3).

This is the output in SmartSnippets

........................................................................................................................
..
.. ERASE QSPI
..
........................................................................................................................
.
cli_programmer 1.26
Copyright (c) 2015-2019 Dialog Semiconductor

bootloader file not specified, using internal uartboot.bin

Uploading boot loader/application executable...
Executable uploaded.

<HERE_IT_HANGS_FOREVER OR UNTIL I UNPLUG THE DEV-KIT>

 

I also attach: ./SDK_10.0.4.66.2/utilities/python_scripts/qspi/jlink.log
I Just noted that the gdbserver command-line sys "-device Cortex-M0" not "Cortex-M33". Is that normal?

SEGGER J-Link GDB Server V6.44i LogFile
Logging started @ 2019-06-17 17:25
03-00000000-00-00000000-0092: Command line: -if swd -device Cortex-M0 -endian little -speed 4000 -select usb=483051972 -port 2331 -swoport 2332 -telnetport 2333 -log jlink.log

03-00000000-00-00000000-01A9: -----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      yes
Generate logfile:              on
Verify download:               off
Init regs on start:            off
Silent mode:                   off
Single run mode:               off
Target connection timeout:     0 ms

03-00000000-00-00000000-014C: ------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 Cortex-M0
Target interface:              SWD
Target interface speed:        4000kHz
Target endian:                 little

03-00000000-00-00000000-0001: 

03-00000000-00-00000028-0018: Connecting to J-Link...

02-00000000-00-00000030-003D: Firmware: J-Link OB-SAM3U128 V3 compiled Jan  7 2019 14:06:26
02-00000000-00-00000030-000F: Hardware: V3.00
02-00000000-00-00000031-000E: S/N: 483051972
02-00000000-00-00000031-0032: TELNET listener socket opened on port 19021WEBSRV 
02-00000000-00-00000031-0029: Starting webserver (0003ms, 0030ms total)
02-00000000-00-00000031-0055: T858FA700 000:028 WEBSRV Webserver running on local port 19080 (0003ms, 0030ms total)
02-00000000-00-00000031-0037: T858FA700 000:028   returns O.K. (0003ms, 0030ms total)
03-00000000-00-00000031-0015: J-Link is connected.

02-00000000-00-00000031-00D3: T858FA700 000:031 JLINK_ExecCommand("device = Cortex-M0", ...). XML file found at: /home/axel/development/igw/git_clones/i1807-road-helmet-1/tools/JLink_Linux_V644i_x86_64/JLinkDevices.xml (0000ms, 0030ms total)
02-00000000-00-00000071-00D4: T858FA700 000:031 /home/axel/development/igw/git_clones/i1807-road-helmet-1/tools/JLink_Linux_V644i_x86_64/JLinkDevices.xml evaluated successfully.Device "CORTEX-M0" selected.  returns 0x00 (0040ms, 0070ms total)
02-00000000-00-00000071-0045: T858FA700 000:071 JLINK_GetFirmwareString(...) (0000ms, 0070ms total)
03-00000000-00-00000071-003E: Firmware: J-Link OB-SAM3U128 V3 compiled Jan  7 2019 14:06:26

02-00000000-00-00000071-0053: T858FA700 000:071 JLINK_GetHardwareVersion()  returns 0x7530 (0000ms, 0070ms total)
03-00000000-00-00000071-0010: Hardware: V3.00

03-00000000-00-00000071-000F: S/N: 483051972

02-00000000-00-00000072-004D: T858FA700 000:071 JLINK_GetHWStatus(...)  returns 0x00 (0001ms, 0071ms total)
02-00000000-00-00000072-0040: T858FA700 000:072 JLINK_EnableSoftBPs(ON) (0000ms, 0071ms total)
03-00000000-00-00000072-001B: Checking target voltage...

03-00000000-00-00000072-0017: Target voltage: 3.30 V

03-00000000-00-00000072-001E: Listening on TCP/IP port 2331

03-00000000-00-00000072-0017: Connecting to target...
02-00000000-00-00000072-0039: T858FA700 000:072 JLINK_ClrError() (0000ms, 0071ms total)
02-00000000-00-00000072-004D: T858FA700 000:072 JLINK_GetHWStatus(...)  returns 0x00 (0000ms, 0071ms total)
02-00000000-00-00000072-0059: T858FA700 000:072 JLINK_TIF_Select(JLINKARM_TIF_SWD)  returns 0x00 (0000ms, 0071ms total)
02-00000000-00-00000072-003D: T858FA700 000:072 JLINK_SetSpeed(4000) (0000ms, 0071ms total)
02-00000000-00-00000072-0048: T858FA700 000:072 JLINK_GetSpeed()  returns 0xA6B (0000ms, 0071ms total)
02-00000000-00-00000072-007B: T858FA700 000:072 JLINK_SetResetType(JLINKARM_RESET_TYPE_NORMAL)  returns JLINKARM_RESET_TYPE_NORMAL (0000ms, 0071ms total)
02-00000000-00-00000072-003F: T858FA700 000:072 JLINK_SetResetDelay(0) (0000ms, 0071ms total)
02-00000000-00-00000072-0059: T858FA700 000:072 JLINK_SetEndian(ARM_ENDIAN_LITTLE)  returns 0x00 (0000ms, 0071ms total)
02-00000000-00-00000076-01D3: T858FA700 000:072 JLINK_Connect() >0x10B TIF>Found SW-DP with ID 0x0BE12477 >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x21 TIF> >0x0D TIF> >0x28 TIF>Scanning AP map to find all available APs >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x21 TIF> >0x0D TIF> >0x21 TIF> >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x21 TIF> >0x0D TIF> >0x21 TIF>AP[1]: Stopped AP scan as end of AP map has been reachedAP[0]: AHB-AP (IDR: 0x14770015)
03-00000000-00-00000180-0062: WARNING: Identified core does not match configuration. (Found: Cortex-M33, Configured: Cortex-M0)

02-00000000-00-00000180-01F2: Iterating through AP map to find AHB-AP to use >0x42 TIF> >0x28 TIF> >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x21 TIF> >0x0D TIF> >0x21 TIF> >0x42 TIF> >0x28 TIF> >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x21 TIF> >0x0D TIF> >0x21 TIF>AP[0]: Core foundAP[0]: AHB-AP ROM base: 0xE00FF000 >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x28 TIF> >0x0D TIF> >0x21 TIF> >0x0D TIF> >0x21 TIF>CPUID register: 0x410FD212. Implementer code: 0x41 (ARM)Found Cortex-M33 r0p2, Little endian.
02-00000000-00-00000184-01F4: Identified core does not match configuration. (Found: Cortex-M33, Configured: Cortex-M0) -- Max. mem block: 0x00005890 -- CPU_ReadMem(4 bytes @ 0xE000EDF0) -- CPU_WriteMem(4 bytes @ 0xE000EDF0) -- CPU_ReadMem(4 bytes @ 0xE0002000)FPUnit: 8 code (BP) slots and 0 literal slots -- CPU_ReadMem(4 bytes @ 0xE000EDFC) -- CPU_WriteMem(4 bytes @ 0xE000EDFC) -- CPU_ReadMem(4 bytes @ 0xE0001000) -- CPU_WriteMem(4 bytes @ 0xE0001000) -- CPU_ReadMem(4 bytes @ 0xE000ED88) -- CPU_WriteMem(4 bytes @ 0xE000ED88)
02-00000000-00-00000187-01DD:  -- CPU_ReadMem(4 bytes @ 0xE000ED88) -- CPU_WriteMem(4 bytes @ 0xE000ED88) -- CPU_ReadMem(4 bytes @ 0xE000EFB8)Security extension: not implementedCoreSight components:ROMTbl[0] @ E00FF000 -- CPU_ReadMem(16 bytes @ 0xE00FF000) -- CPU_ReadMem(16 bytes @ 0xE000EFF0) -- CPU_ReadMem(16 bytes @ 0xE000EFE0) -- CPU_ReadMem(4 bytes @ 0xE000EFBC) -- CPU_ReadMem(4 bytes @ 0xE000EFCC)ROMTbl[0][0]: E000E000, CID: B105900D, PID: 000BBD21 Cortex-M33 -- CPU_ReadMem(16 bytes @ 0xE0001FF0)
02-00000000-00-00000190-01E8:  -- CPU_ReadMem(16 bytes @ 0xE0001FE0) -- CPU_ReadMem(4 bytes @ 0xE0001FBC) -- CPU_ReadMem(4 bytes @ 0xE0001FCC)ROMTbl[0][1]: E0001000, CID: B105900D, PID: 000BBD21 DWT -- CPU_ReadMem(16 bytes @ 0xE0002FF0) -- CPU_ReadMem(16 bytes @ 0xE0002FE0) -- CPU_ReadMem(4 bytes @ 0xE0002FBC) -- CPU_ReadMem(4 bytes @ 0xE0002FCC)ROMTbl[0][2]: E0002000, CID: B105900D, PID: 000BBD21 FPB -- CPU_ReadMem(16 bytes @ 0xE00FF010) -- CPU_ReadMem(16 bytes @ 0xE0042FF0) -- CPU_ReadMem(16 bytes @ 0xE0042FE0)
02-00000000-00-00000192-019B:  -- CPU_ReadMem(4 bytes @ 0xE0042FBC) -- CPU_ReadMem(4 bytes @ 0xE0042FCC)ROMTbl[0][6]: E0042000, CID: B105900D, PID: 000BBD21 CTI -- CPU_ReadMem(16 bytes @ 0xE0043FF0) -- CPU_ReadMem(16 bytes @ 0xE0043FE0) -- CPU_ReadMem(4 bytes @ 0xE0043FBC) -- CPU_ReadMem(4 bytes @ 0xE0043FCC)ROMTbl[0][7]: E0043000, CID: B105900D, PID: 000BBD21 MTB -- CPU_ReadMem(16 bytes @ 0xE00FF020)  returns 0x00 (0120ms, 0191ms total)
02-00000000-00-00000192-00A6: T858FA700 000:192 JLINK_GetIdData(...) >0x0D TIF> >0x21 TIF> ScanLen=4 NumDevices=1 aId[0]=0x0BE12477 aIrRead[0]=0 aScanLen[0]=0 aScanRead[0]=0 (0000ms, 0191ms total)
02-00000000-00-00000192-004C: T858FA700 000:192 JLINK_GetDeviceFamily()  returns 14 (0000ms, 0191ms total)
02-00000000-00-00000192-0051: T858FA700 000:192 JLINK_CORE_GetFound()  returns 0xE0200FF (0000ms, 0191ms total)
02-00000000-00-00000192-0048: T858FA700 000:192 JLINK_IsHalted()  returns FALSE (0000ms, 0191ms total)
02-00000000-00-00000195-0043: T858FA700 000:192 JLINK_Halt()  returns 0x00 (0003ms, 0194ms total)
02-00000000-00-00000195-0047: T858FA700 000:195 JLINK_IsHalted()  returns TRUE (0000ms, 0194ms total)
03-00000000-00-00000195-0014: Connected to target

03-00000000-00-00000195-001D: Waiting for GDB connection...
03-00000000-00-00000195-0017: Connected to 127.0.0.1

03-00000000-00-00000195-001D: GDB closed TCP/IP connection

03-00000000-00-00000305-0017: Connected to 127.0.0.1

00-0000000D-00-00000305-0016: $m00000214,00000005#A5
01-0000000D-00-00000306-0001: +
03-00000000-00-00000306-0025: Reading 5 bytes @ address 0x00000214

02-00000000-00-00000306-00A0: T76BFC700 000:306 JLINK_ReadMem (0x00000214, 0x0005 Bytes, ...) -- CPU_ReadMem(5 bytes @ 0x00000214) - Data: 44 42 47 50 01  returns 0x00 (0000ms, 0194ms total)
01-0000000D-00-00000306-000E: $4442475001#ff
00-0000000D-00-00000306-0017: +$m0000021C,00000004#B3
01-0000000D-00-00000306-0001: +
02-00000000-00-00000306-009D: T76BFC700 000:306 JLINK_ReadMem (0x0000021C, 0x0004 Bytes, ...) -- CPU_ReadMem(4 bytes @ 0x0000021C) - Data: 00 00 00 00  returns 0x00 (0000ms, 0194ms total)
03-00000000-00-00000306-0036: Read 4 bytes @ address 0x0000021C (Data = 0x00000000)

01-0000000D-00-00000306-000C: $00000000#80
00-0000000D-00-00000307-0001: +
00-0000000D-01-00000307-000E: 2458363634632c323a01ff234633
01-0000000D-00-00000307-0001: +
03-00000000-00-00000307-0029: Downloading 2 bytes @ address 0x0000664C

02-00000000-00-00000307-0098: T76BFC700 000:307 JLINK_WriteMem(0x0000664C, 0x0002 Bytes, ...) - Data: 01 FF -- CPU_WriteMem(2 bytes @ 0x0000664C)  returns 0x02 (0000ms, 0194ms total)
01-0000000D-00-00000307-0006: $OK#9a
00-0000000D-01-00000307-0010: 2b24583232382c343a15000000234133
01-0000000D-00-00000307-0001: +
03-00000000-00-00000307-0029: Downloading 4 bytes @ address 0x00000228

02-00000000-00-00000307-009E: T76BFC700 000:307 JLINK_WriteMem(0x00000228, 0x0004 Bytes, ...) - Data: 15 00 00 00 -- CPU_WriteMem(4 bytes @ 0x00000228)  returns 0x04 (0000ms, 0194ms total)
01-0000000D-00-00000307-0006: $OK#9a
00-0000000D-00-00000308-0001: +
00-0000000D-01-00000308-000F: 24583231632c343a01000000234239
01-0000000D-00-00000308-0001: +
03-00000000-00-00000308-0029: Downloading 4 bytes @ address 0x0000021C

02-00000000-00-00000308-009E: T76BFC700 000:308 JLINK_WriteMem(0x0000021C, 0x0004 Bytes, ...) - Data: 01 00 00 00 -- CPU_WriteMem(4 bytes @ 0x0000021C)  returns 0x04 (0000ms, 0194ms total)
01-0000000D-00-00000308-0006: $OK#9a
00-0000000D-00-00000308-0006: +$s#73
01-0000000D-00-00000308-0001: +
03-00000000-00-00000308-001A: Performing single step...

02-00000000-00-00000310-0155: T76BFC700 000:308 JLINK_Step() -- CPU_ReadMem(2 bytes @ 0x00002FC2) -- CPU_ReadMem(4 bytes @ 0xE000ED18) -- CPU_WriteMem(4 bytes @ 0xE000ED18) -- CPU_ReadMem(4 bytes @ 0xE000ED18) -- CPU_WriteMem(4 bytes @ 0xE000ED18) -- CPU_ReadMem(4 bytes @ 0xE0001004) -- CPU_ReadMem(4 bytes @ 0xE000EE08) -- Simulated  returns 0x00 (0002ms, 0196ms total)
02-00000000-00-00000310-0047: T76BFC700 000:310 JLINK_IsHalted()  returns TRUE (0000ms, 0196ms total)
02-00000000-00-00000310-0054: T76BFC700 000:310 JLINK_ReadReg(R15 (PC))  returns 0x00002FC2 (0000ms, 0196ms total)
02-00000000-00-00000310-006E: T76BFC700 000:310 JLINK_GetMOEs(...) -- CPU_ReadMem(4 bytes @ 0xE000ED30)  returns 0x01 (0000ms, 0196ms total)
03-00000000-00-00000310-002A: ...Target halted (DBGRQ, PC = 0x00002FC2)

01-0000000D-00-00000310-0017: $T05thread:0000DEAD;#74
00-0000000D-00-00000310-0006: +$c#63
01-0000000D-00-00000310-0001: +
03-00000000-00-00000310-0017: Starting target CPU...

02-00000000-00-00000310-0047: T76BFC700 000:310 JLINK_IsHalted()  returns TRUE (0000ms, 0196ms total)
02-00000000-00-00000312-00C5: T76BFC700 000:310 JLINK_GoEx(MaxEmulInsts = -1, Flags = 0x00) -- CPU_ReadMem(4 bytes @ 0xE0001000) -- CPU_WriteMem(4 bytes @ 0xE000ED30) -- CPU_WriteMem(4 bytes @ 0xE0001004) (0002ms, 0198ms total)
02-00000000-00-00000312-0048: T76BFC700 000:312 JLINK_IsHalted()  returns FALSE (0000ms, 0198ms total)
02-00000000-00-00000333-0048: T76BFC700 000:332 JLINK_IsHalted()  returns FALSE (0001ms, 0199ms total)
02-00000000-00-00000353-0048: T76BFC700 000:353 JLINK_IsHalted()  returns FALSE (0000ms, 0198ms total)
02-00000000-00-00000374-0048: T76BFC700 000:373 JLINK_IsHalted()  returns FALSE (0001ms, 0199ms total)
02-00000000-00-00000394-0048: T76BFC700 000:394 JLINK_IsHalted()  returns FALSE (0000ms, 0198ms total)
02-00000000-00-00000415-0048: T76BFC700 000:414 JLINK_IsHalted()  returns FALSE (0001ms, 0199ms total)
<SIMILAR PRINTS AS THE LAST ONES JUST KEEP REPEATING FOREVER>

 

PM_Dialog
Offline
Last seen: 7 months 1 week ago
Staff
Joined: 2018-02-08 11:03
Hi rubicoaxel,

Hi rubicoaxel,

Could you please check the jumper’s configuration? I photo would be very helpful. The uartboot.bin is a secondary bootloader in order to load the application binary image. When the device boots, the BootROM code will check the OTP, and if it is not bunt with a secondary bootloader, the uartboot.bin will be loaded which is the default configurations. I cannot see anything wrong in the messages that you got. Did you reset the boards? Also, could you please try to erase/program the QSPI flash through UART?

Thanks, PM_Dialog

rubicoaxel
Offline
Last seen: 2 years 5 months ago
Joined: 2019-05-30 18:29
Hello!

Hello!

Here is a photo of my dev-kit: https://drive.google.com/file/d/1NVgKlmbTPuT9DU0yS34o1FosYikG_K5y/view

UART Erase/Program:
I can't figure out how to erase and/or program trough UART (as you asked me to try).
All information I could find is: https://www.dialog-semiconductor.com/sites/default/files/an-b-069-da1469...
But that only explains the protocol.
I assume there are sw-tools (and hopefully some getting started guide?) following the SDK?
Could you point me to some relevant documentation? 

JTAG Erase/Program: 
Could you help me clearify the process (or point to relevant docs), what part is supposed to do what?
This is my patchy guess of the process so far:

0. Python-script start gdb-server and uses cli_programmer tool to perform actions below
1. JTAG attaches and uploads uartboot.bin by directly writing to RAM (similar to a RAM-debug-session)
2. JTAG executes an SW-reset (again, as I think RAM-debug does it)
3. uartboot.bin executes from RAM and does what?
4. uartboot somehow (?) executes commands given by "<sdk_root>/binaries/cli_programmer" such as
   -"chip_erase_all" or
   -"program_flash" (In which case, how is the actual image transfered? Trough the virtual serial port (/dev/ttyACM0) or by some other means?
 

Or is uartboot.bin read and executed by the bootrom (instead of steps 1-3 above)? If so, is the uartboot.bin transfered trough /dev/ttyACM0  -> debugger usb to uart converter -> da1469x boot uart? What tool at the PC side is responsible for that communication?

And the question 4 remains, once uartboot.bin is started, how are the erase / flash commands transfered to uartboot.bin program running at the target?

Very grateful for any help
Best Regards
Axel

 

PM_Dialog
Offline
Last seen: 7 months 1 week ago
Staff
Joined: 2018-02-08 11:03
Hi rubicoaxel,

Hi rubicoaxel,

Let me check your issue and I will get back to you as soon as possible.

Thanks, PM_Dialog

rubicoaxel
Offline
Last seen: 2 years 5 months ago
Joined: 2019-05-30 18:29
Tank you, much appreciated!

Tank you, much appreciated!

rubicoaxel
Offline
Last seen: 2 years 5 months ago
Joined: 2019-05-30 18:29
Okay, I have solved it!

Okay, I have solved it!

I found the documentation about cli-programmer (SDK_10.0.4.66.2/doc/html/cli_programmer.html) was able to figure it out from there.

Short version: It seems the current program in flash caused gdb to crash. Once i figured out how cli_programmer serial worker and did 

./cli_programmer /dev/ttyACM0 chip_erase_qspi

I was then able to get the JTAG flash python scripts to work an successfully program an image.
If anyone else runs into this, then serial chip-erase is your friend :)

Details (in case someone else wonders):

Using strace on cli_programmer I checked the communication with gdb, and after the final "continue" command issued gdbserver simply stops respondingMy command

axel@axel$ SDK_10.0.4.66.2/binaries$ strace ./cli_programmer gdbserver read_qspi 0 -- 10

Output of gdbserver (last two commands only)

Performing single step...
...Target halted (Vector catch, PC = 0x0000076E)
Starting target CPU...
<Nothing after this>

Output of strace cli_programmer (my comments after #)

# -- single-step
sendto(3, "$s#73", 5, 0, NULL, 0)       = 5  
recvfrom(3, "+", 1, 0, NULL, NULL)      = 1
recvfrom(3, "$T05thread:0000DEAD;#74", 132000, 0, NULL, NULL) = 23
sendto(3, "+", 1, 0, NULL, 0)           = 1
# -- continue
sendto(3, "$c#63", 5, 0, NULL, 0)       = 5 
recvfrom(3, "+", 1, 0, NULL, NULL)      = 1
recvfrom(3, 
<End of reply, waits forever waiting for a gdbserver reply that never arrives>

And in jlink.log we see the endless

02-00000000-00-00000333-0048: T76BFC700 000:332 JLINK_IsHalted()  returns FALSE (0001ms, 0199ms total)

My guess:
is that there is some timing race condition between gdbserver and the program running from flash that causes the debugger to crash and hangs the process. Having an erased flashmemory eliminates the race (between a rouge program in flash and gdb).

Solved som of my questions uartboot.bin
I also managed to anwer my own questions once I got to se some cli_programmer examples.

uarboot.bin is booted by the boot-rom trough the serial-port (not uploaded using GDB as I first thought).
1. On the first execution of cli_programmer it opens and prepares the seralport for boot and then asks the user to press reset to initiate the process of booting uartboot.bin.
2. Once booted, uartboot.bin stays executing (between invocationsand works as a terminal-server for commands given by cli_programmer.
3. On subsequent invocations of cli programmer no boot/reset is needed uartboot.bin its already running.

Final question:
Just one final thing I dont understand.
The serialport is not used at all in jtag mode as far as I can see, so why does the JTAG version of cli_programmer need to upload uartboot.bin (which I understand works as a serial terminal server)?

SDK_10.0.4.66.2/binaries$ ./cli_programmer gdbserver read_qspi 0 -- 10
cli_programmer 1.26
Copyright (c) 2015-2019 Dialog Semiconductor

bootloader file not specified, using internal uartboot.bin

Uploading boot loader/application executable...
Executable uploaded.

00000000   50 70 00 20 00 00 00 20 00 00                                                                     Pp. ... ..                      

 

Best Regards
Axel

 

PM_Dialog
Offline
Last seen: 7 months 1 week ago
Staff
Joined: 2018-02-08 11:03
Hi rubicoaxel,

Hi rubicoaxel,

Glad that you figured you issue out and thanks for your detailed indications.

Can you please clarify you last question?  As I mentioned in my previous comment, the uartboot.bin is a secondary bootloader in order to load the application binary image.

Thanks, PM_Dialog

rubicoaxel
Offline
Last seen: 2 years 5 months ago
Joined: 2019-05-30 18:29
Hi!

Hi!

Yes, in the case of loading application-image trough UART (cli_programmer /dev/ttyACM0 ... ) then uartboot receives the application over the UART and programs it to the QSPI-flash. I'm with you so far.

But in the other case of loading the application over the JTAG  (cli_programmer gdbserver ...), then whats the purpose of uartboot.bin?
Is it still responsible for flashing maybe? like:
1. JTAG uploads application-image to ram
2. uartboot.bin (triggered by the JTAG somehow) copys from RAM to Flash?

These are low-level details an I'ts not important I suppose, I was just curious if you happened to know from the top of your head :)

 

Best Regards
Axel

 

PM_Dialog
Offline
Last seen: 7 months 1 week ago
Staff
Joined: 2018-02-08 11:03
Hi rubicoaxel,

Hi rubicoaxel,

As uartboot.bin is he intermediate bootloader that cli_programmer uses for communicating with the target. The uartboot firmware will automatically detect the device variant. The uartboot is been using as a secondary bootloader in order to load the binary image to the device.

Thanks, PM_Dialog