XMC1400 Setting BMI on new chips / parts

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
sca
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hello,

This is a follow on to the following query:

https://community.infineon.com/t5/XMC/Moving-from-XMC1400-Xtreme-to-custom-board/td-p/344604

The solution in that post from Vasanth worked on a couple of prototype boards and we've ben able to debug and develop the project.

We now appear to be back at the same issue in getting new chips up and communicating with debug tools for test / programming.

On a batch of 5 boards, only one responds correctly to the procedure outlined for setting up BMI. The other four will not connect to either the XMC flasher tool, or Dave.

Pressing the Connect button on XMC flasher results in a debugger exception, and an invitation to check the log file, which is as follows:

INFO-com.infineon.XMCFlasher.MainAppController-main: Logger Name: com.infineon.XMCFlasher.MainAppController
INFO-com.infineon.XMCFlasher.SeggerLibLoad-configureLoad: Not Found property: xmcFlasher.JLink.dllPath Searching in registry key
INFO-com.infineon.XMCFlasher.SeggerLibLoad-configureLoad: Setting property: bridj.JLinkARM.library to: C:\Program Files\SEGGER\JLink\JLink_x64.dll
INFO-com.infineon.XMCFlasher.SeggerLibLoad-configureLoad: Not Found property: xmcFlasher.JLink.dllPath Searching in registry key
INFO-com.infineon.XMCFlasher.SeggerLibLoad-configureLoad: Setting property: bridj.JLinkARM.library to: C:\Program Files\SEGGER\JLink\JLink_x64.dll
INFO-com.infineon.XMCFlasher.SeggerDLL-checkAvailabilityAndLoad: Loaded JLink DLL 7.54.d
INFO-com.infineon.XMCFlasher.MainAppController-start: Starting Application in process ...
WARNING-com.infineon.XMCFlasher.view.RootLayoutOverviewController-handleConnect: com.infineon.XMCFlasher.DebuggerExceptions: Error get BMI value
WARNING-com.infineon.XMCFlasher.view.RootLayoutOverviewController-handleConnect: com.infineon.XMCFlasher.DebuggerExceptions: Error get BMI value
WARNING-com.infineon.XMCFlasher.view.RootLayoutOverviewController-handleConnect: com.infineon.XMCFlasher.DebuggerExceptions: Error get BMI value
WARNING-com.infineon.XMCFlasher.view.RootLayoutOverviewController-handleConnect: com.infineon.XMCFlasher.DebuggerExceptions: Error get BMI value

Connection is not established - we get no info in the Unique Chip ID field.

This process works fine on one of our 5 boards and our prototype.

 

All boards appear to be well soldered, and buzz through on power / SWD connections fine.

All chips are as in the previous post - marking 1400 X 200A 6JG1725

Scoping P0.14 on power up sees the pin pulled up - according to 27.1.3 of the device manual, this should indicate that the startup software (SSW) is running.

Probing P0.14 / P0.15 during comms from XMC flasher appears to show clean signals.

How can I get these boards up and running? 

 

Thanks,

 

Simon Ansley

0 Likes
2 Replies
Vasanth
Moderator
Moderator
Moderator
250 sign-ins 500 solutions authored First question asked

Hi Simon,

Hope you are doing good! Can you check one more thing? SWDIO_1 pins (P1.2 and P1.3) could be the active ones. Can you connect the following pins externally to the debugger using two wires, so that (pin 1.3 and SWD) and (Pin 1.2 and SWCLK) are used to connect to the debug interface and change the BMI using the same method?

Best Regards,
Vasanth 

0 Likes
sca
Level 1
Level 1
5 sign-ins First reply posted First question asked

Hello, Vasanth,

I just had time to try this, and it works.

This is good news from one point of view, and very bad from another. 

It essentially means that the chips are coming from the factory with the debug port seemingly assigned at random - we've assembled something around 10 boards of various iterations, all with brand new chips, with 3 which connected fine (using P0.14,15), this one connecting on P1.2,3 and all others not responding on those pins, but, given the symptoms, presumably also on P1.2,3.

The user manual 27.2.2 gives a delivery state value of #xFFC0, which would put the value 0x3 in the DAPDIS field, which is undefined.

We currently have a USB-Serial converter connected to P1.2,3 on the board. I guess I'd have to jumper the connection to the SWD header to allow me to use either set of pins, but that seems very odd - I'd expect defined behaviour on brand new chips.

Am I missing something?

Simon Ansley

 

0 Likes