- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
In order to reduce the PCB size and overall cost of one of our products based on a Murata 1GC module, we have manufactured new boards with a new power supply system on which we are experiencing debug/flash issues.
Indeed, we are unable to program the flash memory, we tried with Olimex USB Tiny-H and Jlink (SWD and JTAG).
There is activity on the SPI flash bus, so the MCU seems boot up and runs the ROM bootloader.
We double checked every bootstrap pins and every power lines, everything is fine, the only thing is that the Cortex R4 cannot enter in debug state, while the JTAG chain is found by the debugger.
On our previous release (with another power supply stage) everything works fine, what could explain this kind of behaviour ?
EDIT: I forgot to mention that the boards have been checked under X-ray to detect manufacturing defects.
Thank you.
Log messages from J-Link commander when we try to connect:
JTAG:
J-Link>connect
Device "CYW43907" selected.
Connecting to target via JTAG
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: APB-AP (IDR: 0x44770002)
AP[1]: JTAG-AP (IDR: 0x24760010)
Iterating through AP map to find APB-AP to use
AP[0]: APB-AP found
ROMTbl[0][0]: CompAddr: 80001000 CID: B105900D, PID:04-008BBC14 Cortex-R4
Found Cortex-R4 r1p4
4 code breakpoints, 4 data breakpoints
Debug architecture ARMv7.0
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
****** Error: Timeout while entering debug state
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
Cannot connect to target.
J-Link>
SWD:
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
****** Error: Timeout while entering debug state
Cortex-A/R (connect): Communication error when trying to read IDR of AP[0].
Found SW-DP with ID 0x5BA02477
Found SW-DP with ID 0x5BA02477
****** Error: Cortex-A/R (connect): Communication error when trying to read IDR of AP[0].
when trying to read IDR of AP[0].
Cannot connect to target.
J-Link>
On our previous (working) board:
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 enabled
Level-1 data cache enabled
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>
- Labels:
-
Wireless MCU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In the new power supply system, Did you the change the Vddio/Vbat levels? Will it be possible for you to share the changes (or attach the schematic in a private conversation, maybe)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Vbat and VDDIO are set to 3.3V, coming from a step down regulator, for both board releases.
Yesterday, we unsoldered all the not critical components (I2C devices, audio codec, power button management, even the SPI flash), and powered it with external PSU, but we still have the same issue.
EDIT: I sent you a private message.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After several hours of checking, we finally did a last test, we swapped the flash memories from a CYW943907AEVAL1F eval board and one of our PCBs.
The flash from eval board was previously programmed with the onboard debugger.
And ... IT DOES WORK !
The pre-programmed eval board flash soldered on our PCB allows the MCU to enter in debug mode (and program the flash).
And the blank flash soldered on the eval board can also be programmed by the onboard debugger, so the flash IC was not defected.
So, what could prevent the MCU to enter in debug state in presence of blank flash memory?
On our previous PCBs, we don't have this issue, the blank flash can be programmed with JLink or Olimex USB-TINY-H.
Similar (unresolved) issue here: CYP43907 JTAG/SWD connect issue
EDIT: I forgot to mention that we use J-Link to program the flash memory (tried JTAG and SWD).
Command: make %TARGET% JLINK_NATIVE=1 JLINK_PATH=%PATH_TO_JLINK% JLINK_EXE="Jlink.exe" download
Result (JLink JTAG):
VTref=3.299V
Target connection not established yet but required for command.
Device "CYW43907" selected.
Connecting to target via JTAG
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: APB-AP (IDR: 0x44770002)
AP[1]: JTAG-AP (IDR: 0x24760010)
Iterating through AP map to find APB-AP to use
AP[0]: APB-AP found
ROMTbl[0][0]: CompAddr: 80001000 CID: B105900D, PID:04-008BBC14 Cortex-R4
Found Cortex-R4 r1p4
4 code breakpoints, 4 data breakpoints
Debug architecture ARMv7.0
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
****** Error: Timeout while entering debug state
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
TotalIRLen = 4, IRPrint = 0x01
JTAG chain detection found 1 devices:
#0 Id: 0x5BA00477, IRLen: 04, CoreSight JTAG-DP
Cannot connect to target.
[Repeated several times]
We cannot use Olimex USB-TINY-H on these PCBs (defected unit).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In a nutshell: we are not able to program a blank flash with JLink tools (jlink, jflash / JTAG, SWD), while it does work with a programmed one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
For the blank flash case, can you connect to the core now using J-Link?
If you are able to connect to the core, can you read or erase it?
Because CYW4390x was not in the list of J-link supported devices, you would need to follow certain steps like placing the JLinkDevices.xml as mentioned Downloading through Jlink Segger in WICED SDK 6.2 and future releases
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, I can not connect to the core using J-Link when the flash is blank, it only works when the flash is already programmed.
It seems that, when the CPU (actually, the ROM bootoader) doesn't find the right signature in the external memory it enters in a state where debug mode is not allowed, and then can not program the flash (using sflash-write code).
Latest versions of J-Link tools have native support for CYW43907. JFlash works out of the box (when the flash is not empty ...).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We tried to reproduce this issue with the CYW943907AEVAL1F board, by erasing the memory with the onboard debugger (using sflash_erase command from sflash_write script) and reprogramming it with JLink using the J3 header.
Unfortunately (or fortunately), J-Link does work in this situation, while our design is mainly based on the eval board schematics.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Good to know that the support has been added in the Segger side.
But the eval kit working makes it even harder for us to debug the issue. When you are not being able to connect, can you have the sflash erase operation Unbricking of CYW943907 while loading the code (Downloading dct part atleast) and see if that makes a difference.
Additionally, do a HIB_REG_ON_IN to High -> Low -> High in the failure case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
JoLE_3168931:
On our previous PCBs, we don't have this issue, the blank flash can be programmed with JLink or Olimex USB-TINY-H.
Well, actually, it is not true.
We are not able to program a blank flash on our previous PCB either, at least with SWD (for other reasons we could not use JTAG). Unable to connect. We need to use the Olimex debugger in this situation.
But even the Olimex debugger can not program the flash on the new PCB, so we have refocused our attention on this configuration (Olimex/new PCB).
And we have found something strange, when the debugger starts to communicate, the JTAG TCK clock signal is too weak, it has a high level lesser than 1V, The other JTAG signals are fine. Before to start flashing, TCK is fine at 3.3V. And, when we use SWD, even if it fails to connect, the TCK signal is fine, it only occurs with Olimex debugger in JTAG. It is like the Wi-Fi module configures the TCK pin as an output.
We don't encounter this issue with our previous PCB and the exactly same debugger and cable, and remember it only occurs when the flash is blank.
Is there any chance that the ROM bootloader has been changed in the last few months? The previous PCBs have been manufactured in October, the new ones in April.
We have planned to swap the Wi-Fi modules between our PCBs, to be sure that the issue is caused by our new design (or not).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, ROM bootloader has not been changed in the past few months. So, you can rule that out.