TC39B BSL firmware update fail

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

cross mob
User19664
Level 1
Level 1
5 replies posted Welcome! First question asked
I tried to flash my firmware file onto a TC39B device with memtool over BSL. I got the same error every time after the flashing has been started, and it fails exactly at the same address.
Is there something I forget to configure before flashing that could cause this error?

4372.attach
0 Likes
9 Replies
NeMa_4793301
Level 6
Level 6
10 likes received 10 solutions authored 5 solutions authored
Since the error is on the read... can you try erasing flash first?
0 Likes
User19664
Level 1
Level 1
5 replies posted Welcome! First question asked
Sure, I've tried erasing the entire flash first, then flashing the device, but I got the same.
According to the datasheet this memory address is located in the Program Flash 1 (PF1). Is it possible that this is sector is protected?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
You could find out if protection has been set by looking at the HP_PROCONPiP registers - this will tell you whether any was set.

When doing the erase, did you do just an erase, or an erase-verify (i.e. erase verify logical sector range)?
0 Likes
User19664
Level 1
Level 1
5 replies posted Welcome! First question asked
I've checked with the memtool, in the UCB_PFLASH tab all the PROCONP register have 0x0000000 values for PFLASH0-5.
I did not find an erase-verify option in memtool, however I ran a device empty test. All of the sectors shown empty there.

I've removed all sectors which are not located in PFLASH0, and this time flashing was done successfully. Is it possible that I can only program PFLASH0 with memtool over serial BootStrapLoader(BSL)?
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
You could also check the one-time programmable PROCONOTP/WOP - if they are set, then flashing won't work after the first one.
0 Likes
User19664
Level 1
Level 1
5 replies posted Welcome! First question asked
Where can I find the PROCONOTP/WOP in memtool?

I could not find anything that could cause this flashing problem. It seems to me that basically everything is set to default.
Here are all my UCB setting read with memtool:
4470.attach4469.attach4468.attach4467.attach4465.attach4466.attach
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
The OTP is set in UCB_OTPx, which starts at 0xAF40_4000, but this doesn't seem to be available to you in this tool, which I am not familiar with. Is there any other information anywhere apart from "failed" - any log messages etc?
0 Likes
User19664
Level 1
Level 1
5 replies posted Welcome! First question asked
This is the only log I can get from memtool. Unfortunatelly does not contain more information about the cause of the failure.

----------------------------------------------------------

Connection Failed Report from
Infineon Memtool Target Interface, Version: 1.17.3
created: 06/19/20, 12:31:54

----------------------------------------------------------

Windows version:
Win8 ()
Admin: yes

IMT version:
Release: 4.08.01
Build: 4807
Path: C:\Program Files (x86)\Infineon\Memtool 4.8

Target configuration file:
C:\Users\marton.zsebok\workspace_ctc_v6.3r1\led_blink\Debug\TriBoard_TC39x.cfg

Error messages:
MiniMonTargIntf: Connection to target lost !
MiniMonTargIntf: Read memory block 0x00000000A031E00C-0x00000000A031E01F failed !
MiniMonTargIntf: Monitor protocol failed

Settings:
PortNum: 0
PortType: COMX
PortSel: Keyspan USB Serial Port
ReqReset: n
ReqResetMsg:
ResetOnConnect: y
ResetWaitTime: 500
ExecInitCmds: n
ExtStartMode: n
InitScript Script:
Script is empty
BaudRate: 57600
KLineProt: n
UseRS232Drv: y
CanPortNum: 1
AssureSendOfComPort: n
Stm32AscBaudrateForConnect: 0
MonType: ASC
CheckAckCode: y
AlwaysEINIT: n
UseExtMon: n
MonitorPath:
LoaderStart: 0xC0000000
LoaderSize: 0x00000080
UseExtMon2: n
Mon2Path:
Mon2Start: 0xFFFFFFFF
SCRMSupport: n
SCRMBaudRate: 0
RSTCON_H: 0x00
S0BRL: -1
UseChangedBaudRate: n
Sv2PLLCON: 0x7103
Sv2ASC0BG: 0xFFFF
Sv2CANBTR: 0xFFFF
TcPllValue: 0x00000000
TcPllValue2: 0x00000000
TcPllValue3: 0x00000000
TcAscBgValue: 0x00000000
TcCanBtrValue: 0x00000000
XC2000ScrmClock: 40000000
XC2000ScrmPllValue:
XC2000ScrmBrgValue:
MaxReadBlockSize: 0
BootPasswd0: 0xFEEDFACE
BootPasswd1: 0xCAFEBEEF
DasDllPath: das_api.dll
DasHost:
DasTryStartSrv: y
DasSrvPath: servers\udas\udas.exe
DasStopSrv: y
DasResetMode: 2
DasRemoveLogFile: n
DasSrvSel: -1
DasPortType: 0
DasPortSel: 0
AurixEdBootWorkaround: n

Info:
ArchType: 3
Architecture: TriCore
TcDerivate: 0
IsXC2x: n
IsStm32: n
ExtClock: 20000000
IntClock: 100000000
SysClock: 100000000
PllCalc: UDE.TC39xPllCalc
PllValueCount: 1
UsedComPort: 8
CurrBaudRate: 57600
CurrMonImage: TriCore.Asc.TC39x.Def
AscBslAllowed: y
CanBslAllowed: n
ScrmSupport: n
CanScrmSupport: n
AscBslForceKLine: n
CanBslBug: n
TcCanBslMode: 0
Tc1797AscBslBug: n
AurixKlineBug: n
AbmModeDetected: n
0 Likes
Darren_Galpin
Employee
Employee
First solution authored First like received
The address of failure is in PFlash1, and assuming that you are reading back in sequence, this mean that the read back from PFlash0 was correct and worked. The address which has failed is not at an obvious boundary, so it wouldn't be protection. It would be good to know if there were any errors reported when performing the read. Forgive my complete lack of knowledge over what you are running and the tools, but while running the memtool are you able to run register reads at all? It would be good to know what error the CPU was reporting when performing the read, and whether any ECC errors are being reported by the flash when being read.
0 Likes