cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

SeFe_4295646
New Contributor II

Greetings,

We're having an issue connecting to SOME of our prototype hardware via Seger JLINK  SWD mode.  It works fine on some boards but not others.  While I cannot yet rule out some manufacturing defect - if there is one its not revealed in a 3d x-ray of the PCBA.

Our problem is described in this thread [CYW43907] MCU JTAG Connect Fail but the answer is not very helpful other than we may be looking in the wrong direction.

To be clear, we're using a Murata 1GC module.

Build options are: JTAG=jlink-native JLINK_PATH="/usr/bin/" JLINK_EXE="JLinkExe" JLINK_INTERFACE=SWD download download_apps

Build machine is linux based - but replicated on a Windows 10 platform (with appropriate changes in above for windows machines.

Error text is:

****** Error: Cortex-A/R (connect): Failed to temporarily halting CPU for reading CP15 registers.

Cannot connect to target.

I've tried using JLinkExe from the command line, on a working target:

sean_fendt@ssf:~/src/tf0001$ JLinkExe -device CYW43907 -if SWD -speed 4000
SEGGER J-Link Commander V6.52e (Compiled Oct 16 2019 12:19:21)
DLL version V6.52e, compiled Oct 16 2019 12:19:11

Connecting to J-Link via USB...O.K.
Firmware: J-Link V9 compiled May 17 2019 09:50:41
Hardware version: V9.30
S/N: 59304943
License(s): GDB
VTref=3.354V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Device "CYW43907" selected.


Connecting to target via SWD
Found SW-DP with ID 0x5BA02477
CoreSight AP[0]: 0x44770002, APB-AP
ROMTbl 0 [0]: 00001003, CID: B105900D, PID:04-008BBC14 Cortex-R4
Found Cortex-R4 r1p4
4 code breakpoints, 4 data breakpoints
Debug architecture ARMv7.0
Data endian: little
Main ID register: 0x411FC144
I-Cache L1: 32 KB, 256 Sets, 32 Bytes/Line, 4-Way
D-Cache L1: 32 KB, 256 Sets, 32 Bytes/Line, 4-Way
TCM Type register: 0x00010001
MPU Type register: 0x00000800
System control register:
  Instruction endian: little
  Level-1 instruction cache disabled
  Level-1 data cache disabled
  MPU enabled
  Branch prediction enabled
Memory zones:
  [0]: Default (Default access mode)
  [1]: APB-AP (AP0) (DMA like acc. in AP0 addr. space)
Cortex-R4 identified.
J-Link>q

And on a non-working target:

sean_fendt@ssf:~/src/tf0001$ JLinkExe -device CYW43907 -if SWD -speed 4000
SEGGER J-Link Commander V6.52e (Compiled Oct 16 2019 12:19:21)
DLL version V6.52e, compiled Oct 16 2019 12:19:11

Connecting to J-Link via USB...O.K.
Firmware: J-Link V9 compiled May 17 2019 09:50:41
Hardware version: V9.30
S/N: 59304943
License(s): GDB
VTref=3.353V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Device "CYW43907" selected.


Connecting to target via SWD
Found SW-DP with ID 0x5BA02477
CoreSight AP[0]: 0x44770002, APB-AP
ROMTbl 0 [0]: 00001003, CID: B105900D, PID:04-008BBC14 Cortex-R4
Found Cortex-R4 r1p4
4 code breakpoints, 4 data breakpoints
Debug architecture ARMv7.0
Found SW-DP with ID 0x5BA02477
CoreSight AP[0]: 0x44770002, APB-AP
ROMTbl 0 [0]: 00001003, CID: B105900D, PID:04-008BBC14 Cortex-R4
Found Cortex-R4 r1p4
4 code breakpoints, 4 data breakpoints
Debug architecture ARMv7.0

****** Error: Cortex-A/R (connect): Failed to temporarily halting CPU for reading CP15 registers.

Found SW-DP with ID 0x5BA02477
CoreSight AP[0]: 0x44770002, APB-AP
ROMTbl 0 [0]: 00001003, CID: B105900D, PID:04-008BBC14 Cortex-R4
Found Cortex-R4 r1p4
4 code breakpoints, 4 data breakpoints
Debug architecture ARMv7.0
Found SW-DP with ID 0x5BA02477
CoreSight AP[0]: 0x44770002, APB-AP
ROMTbl 0 [0]: 00001003, CID: B105900D, PID:04-008BBC14 Cortex-R4
Found Cortex-R4 r1p4
4 code breakpoints, 4 data breakpoints
Debug architecture ARMv7.0

****** Error: Cortex-A/R (connect): Failed to temporarily halting CPU for reading CP15 registers.

Cannot connect to target.
J-Link>q

I have the feeling something is on the edge of working, but so far I don't know what.  Extensive experiments with strapping, reset timing, etc has not been revealing.  Any thoughts on things to check would be helpful.

0 Likes
11 Replies
Zhengbao_Zhang
Moderator
Moderator

BCM43907 Flashing through Uart and JTag (con't)

Would you please check this point ?

try add following line into jlink.cfg

reset_config trst_and_srst srst_push_pull srst_nogate connect_assert_srst

MichaelF_56
Moderator
Moderator

SeFe_4295646

Have you had a chance to add the line to the jlink.cfg file that ZhengbaoZ_96​ recommended?

0 Likes
SeFe_4295646
New Contributor II

Trying to do that - but our target does not connect RESET to the JLink (we do have TRST, but not the chip reset, have never needed it in past designs) - I can manually make the connection and am in process of doing so to test further.  Will have more detail today.

0 Likes
SeFe_4295646
New Contributor II

Ok - that may have made some minor differences but did NOT solve the problem.  A board I could not previously communicate with at all did initially start to program the DCT area, but then I got:

Memory access: CPU temp. halted: https://wiki.segger.com/Memory_accesses#Stop_mode

**************************

WARNING: Register 75 (R9) could not be written. Reason: CPSR indicates a non-valid CPU mode.

**************************

**************************

WARNING: Register 80 (R14) could not be written. Reason: CPSR indicates a non-valid CPU mode.

**************************

**************************

WARNING: CPU could not be halted

**************************

programming subsequent files (file-system, apps, etc) failed to connect until power cycled.

I've had intermittent issues before, so cannot guarantee the connecting the rest line and adding to jlink.cfg is responsible for the progress made.

Just to be sure, I fould 2 copies of jlink.cfg and changed both, but would like to confirm that one of these is the correct file to edit:

./WICED-Studio-6.4/43xxx_Wi-Fi/tools/OpenOCD/scripts/interface/jlink.cfg
./WICED-Studio-6.4/43xxx_Wi-Fi/tools/OpenOCD/jlink.cfg

0 Likes
Zhengbao_Zhang
Moderator
Moderator

I think this one.

./WICED-Studio-6.4/43xxx_Wi-Fi/tools/OpenOCD/jlink.cfg

0 Likes
SeFe_4295646
New Contributor II

Well I have been able to prove that the change does make a difference, if nRESET from the JTAG is connected to the RESET in on the UUT,

Specifically this sequence (without config file change or without RESET connection):

Reset delay: 0 ms

Reset type NORMAL: Reset CPU + peripherals via reset pin. CPU halted immediately after reset.

ResetTarget() start

J-Link script: Reset

J-Link script: Core did not halt after reset. Halting core...

J-Link script: Done

ResetTarget() end

becomes this:

Reset delay: 0 ms

Reset type NORMAL: Reset CPU + peripherals via reset pin. CPU halted immediately after reset.

ResetTarget() start

J-Link script: Reset

J-Link script: Done

ResetTarget() end

So I'm convinced the change does something, BUT this does not solve the problem.

Boards that program seem to program with or without the reset pin connection.


One other observation: Some boards are still intermittent, some work always, some never.  The intermittent boards seem to work more reliably at JLINK_SPEED=7000 than 4000.  Slower than 4000 seems to make it worse.

0 Likes
SeFe_4295646
New Contributor II

New information.

I took sample A - proto that I cannot program SWD, gives me the errors above, and the external flash from one that programmed normally, place the flash from the working unit in place of the blank flash on the non-working unit, the non-working unit not only ran the firmware on the flash successfully, but I was then able to program it reliably after the swap.

The flash is a Cypress S25FL128LAGMFI013

0 Likes
Zhengbao_Zhang
Moderator
Moderator

thanks for the info,   so assume S25FL128LAGMFI013 is working always even after the re-work to the bad one.

we should have a supported flash list in the release.

Would you please check spi_flash.c in the WICED\platform\MCU\BCM4390x\peripherals\spi_flash

cy flash supported list is here:

#ifdef SFLASH_SUPPORT_CYPRESS_PARTS

        { SFLASH_ID_S25FL064L,       { 8*MBYTE,    256,  .action = &cypress_action,  .speed_advance = &cypress_speed_config } },

        { SFLASH_ID_S25FL128L,       { 16*MBYTE,   256,  .action = &cypress_action,  .speed_advance = &cypress_speed_config } },

        { SFLASH_ID_S25FL256L,       { 32*MBYTE,   256,  .action = &cypress_action_over_128Mbit,  .speed_advance = &cypress_speed_config } },

#endif /* SFLASH_SUPPORT_CYPRESS_PARTS */

Zhengbao_Zhang
Moderator
Moderator

you can add the sflash support in the platform makefile

like CYW943907AEVAL1F.mk :

GLOBAL_DEFINES += SFLASH_SUPPORT_MACRONIX_PARTS

SeFe_4295646
New Contributor II

We've added the part to our platform a long time ago, as you suggest above, double checked.


What I don't understand is how this can have any affect before the device is programmed?  We can't do the initial programming of the device (prototypes have blank flash devices populated, we do our programming over JTAG or SWD).

If we are able to program the device it works normally, so yes we are are confident the device is supported in the code.  The same code, and flash device part number, are used on working and non-working boards.

0 Likes
SeFe_4295646
New Contributor II

Still having the same problem.

Have connected reset as suggested, verified the J-Link reset configuration, verified support of the flash device.

If we place a programmed part on boards we cannot program via J-Link they work.  And in many cases remain re-programmable via J-Link, but not all the time.  (If fully erased, it becomes UNprogrammable again).

Need to solve this urgently, any advice / recommendations welcome at this point.

Thanks

0 Likes