STEVAL-IDB007V2's BlueNRG-1 vs. IAR EWARM 8.20.2 w/ segger j-link

howard n2wx · ‎2018-06-26

Posted on June 26, 2018 at 23:21

Has anyone else encountered and solved a 'can't halt cpu' issue in IAR EWARM when using the segger j-link to program the BlueNRG-1 part through the 20 pin IDC jtag port on the STEVAL-IDB007V2? If so could you share the fix?

I can read and flash the BlueNRG-1 through J-Link commander but that's not a good debug environment. I also have a couple of ST-Link v2s here but those throw errors claiming inability to connect to the CPU.

With the J-link IAR's debug log is as follows:

Tue Jun 26, 2018 17:10:39: IAR Embedded Workbench 8.20.2 (C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\arm\bin\armproc.dll)

Tue Jun 26, 2018 17:10:40: JLINK command: ProjectFile = C:\Users\hgoldstein\Documents\ST\BlueNRG-1_V1 DK 1.0.0\Project\BLE_Examples\BLE_Chat\EWARM\settings\BLE_Chat_Client.jlink, return = 0

Tue Jun 26, 2018 17:10:40: Device 'BLUENRG1' selected.

Tue Jun 26, 2018 17:10:40: Selecting SWD as current target interface.

Tue Jun 26, 2018 17:10:40: JTAG speed is fixed to: 1000 kHz

Tue Jun 26, 2018 17:10:40: Found SW-DP with ID 0x0BB11477

Tue Jun 26, 2018 17:10:40: Scanning AP map to find all available APs

Tue Jun 26, 2018 17:10:40: AP[1]: Stopped AP scan as end of AP map has been reached

Tue Jun 26, 2018 17:10:40: AP[0]: AHB-AP (IDR: 0x04770021)

Tue Jun 26, 2018 17:10:40: Iterating through AP map to find AHB-AP to use

Tue Jun 26, 2018 17:10:40: AP[0]: Core found

Tue Jun 26, 2018 17:10:40: AP[0]: AHB-AP ROM base: 0xE00FF000

Tue Jun 26, 2018 17:10:40: CPUID register: 0x410CC200. Implementer code: 0x41 (ARM)

Tue Jun 26, 2018 17:10:40: Found Cortex-M0 r0p0, Little endian.

Tue Jun 26, 2018 17:10:40: FPUnit: 2 code (BP) slots and 0 literal slots

Tue Jun 26, 2018 17:10:40: CoreSight components:

Tue Jun 26, 2018 17:10:40: ROMTbl[0] @ E00FF000

Tue Jun 26, 2018 17:10:40: ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB008 SCS

Tue Jun 26, 2018 17:10:41: ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 000BB00A DWT

Tue Jun 26, 2018 17:10:41: ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 000BB00B FPB

Tue Jun 26, 2018 17:10:41: Executing ResetTarget()

Tue Jun 26, 2018 17:10:42: BL reset: Timeout while waiting for CPU to halt after reset. Manually halting CPU.

Tue Jun 26, 2018 17:10:42: Warning: CPU could not be halted

Tue Jun 26, 2018 17:10:42: Hardware reset with strategy 0 was performed

Tue Jun 26, 2018 17:10:42: Initial reset was performed

Tue Jun 26, 2018 17:10:59: Executing ResetTarget()

Tue Jun 26, 2018 17:10:59: BL reset: No application found. Manually halting CPU.

Tue Jun 26, 2018 17:10:59: Warning: CPU could not be halted

Tue Jun 26, 2018 17:10:59: Hardware reset with strategy 0 was performed

Tue Jun 26, 2018 17:10:59: Initial reset was performed

Tue Jun 26, 2018 17:11:05: IAR Embedded Workbench 8.20.2 (C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.0\arm\bin\armproc.dll)

I tried most of the reset options with the same results. Thanks!

#bluenrg-1 #segger #iar #st-link #ewarm #j-link

Antonio Vilei · ‎2018-06-27

Posted on June 27, 2018 at 10:09

Hi Howard,

do you have any STM32 Nucleo board? If yes, you could use the embedded ST-LINK/V2-1 of your Nucleo by means of the SWD pins.

Best regards,

Antonio

howard n2wx · ‎2018-06-27

Posted on June 27, 2018 at 19:53

Hello Antonio, thanks for your reply. I'll try a Nucleo if I run into the issue again. A workaround that got me running involved holding down the eval board's reset button and releasing it just as I depressed the program-flash button on IAR's IDE. It took 5 or 10 tries but eventually I timed it correctly and wound up at a dialog complaining that the part was protected and asking if I wanted to mass erase it. I saved off the flash contents before allowing the mass erase and afterwards I can now program and debug the bluenrg-1.

Winfred LU · ‎2018-06-27

Posted on June 28, 2018 at 03:33

Hi Howard,

Could you please try to

force IO7 pin high during HW resetting the device?

It sounds like you were seeing some situation where SWD cannot be accessed when:

application that set the device in sleep or standby state, which the debug port (SWD) is not powered.

Thank you.

Best Regards,

Winfred

howard n2wx · ‎2018-06-28

Posted on June 28, 2018 at 15:28

Thank you WInfred, in that I've flashed this puppy a half dozen more times since I first had the issue and it didn't crop up again your diagnosis sounds spot-on. Around mid-summer I expect to be told to develop a battery powered device and expect I'll have a chance to use your solution to flash it. Best Regards, Howard