TMS320F28377D: TMS320F28377D: C28xx_CPU1: Flash Programmer: Warning: The configured device (TMS320F28377D) does not match the detected device (). - Still present after component replacement

Clément

A clarification please:  The new device (F2837xD) that you used on this board was proved to be working fine on another board already?  

Thanks and regards,
Vamsi

Hi,

Well no obviously not, our process doesn't allow us to re-use a processor that has undergone an unsoldering.

So this new processor was a fresh one.

Clément

Clément,

Does this also show similar TI-OTP content like the one you shared earlier in the previous post?

You never succeeded to load code to RAM or Flash on this device - correct?

Please note: I will be out of office on 8/20/2021.

Thanks and regards,

Vamsi

Vamsi,

Yeah as you can see it does.

OTP:

DSCM:

Aparrently my colleague discovered a strange behavior that led to it working, I have to investigate.

Clément

Vamsi,

So apparently, they activated the GPIO36 (which we use for a maintenance SW activation in our design) and in that configuration it worked.

Then after that with or without this GPIO activation it works.

I honestly don't understand why as this GPIO doesn't seem to have anything particular.

Any idea ?

Regards,

Clément

Clément,

We may need more info to analyze.  What do you meant by activating GPIO36?  Are you saying that after a SW upgrade, the device started working fine?  Did you analyze the differences between the two versions?  

Thanks and regards,
Vamsi

Vamsi,

The device was non programmed as we had replaced it as discussed.

It was stuck with the above error till we set that GPIO to 1 and then loaded SW and then with or without the GPIO set to 1 it works.

Regards,

Clément

Clement,

What is the boot mode pin configuration used?  

I may loop in our system control expert to analyze this further for you.

Thanks and regards,

Vamsi

The device was unprogrammed so nothing was configured at first.

Regards,
Clément

Clément,

My question is related to the boot pin configuration on the board.

Thanks and regards,

Vamsi

Vamsi,

We use GPIO54/GPIO55.

Clément

Clément,

Ok.  Are they configured for flash boot?  Can you try wait-boot?

Please note: I assigned this to our system control expert to help you further.  

Thanks and regards,
Vamsi

I can not think of any relation of device working with GPIO36 driven high unless there is some issue on board where forcing GPIO36 to high driving some other pin high hence making a difference in device behavior. Since this is fresh device, there should not be any issue with security. Can you post the snapshot of OTP and USER OTP (DCSM setting) with GPIO 36 driven high. Also please take a snapshot of all  GPIO DATA register in both case (with GPIO36 driving high and without driving it).

Regards,

Vivek Singh

Well I totally agree with you it's totally odd.

And as I said, after that magical operation, we are now having no issue...

Not sure it needs further investigation for now, was just trying to see with you if there was something that didn't come to my mind and would explain.

Clément

Hi,

Clément Letonnelier said:

And as I said, after that magical operation, we are now having no issue...

Does that mean, even if you power cycle the board now, you don't see any issue ? We can close it for now and if you see this issue again, you can re-open this post or start a new one.

Regards,

Vivek Singh

Hi,

Yes exactly... as I said magical !

I was trying to find out an explanation.

Clément

Hi Vivek Singh,

The magic didn't last... The problem is back.

Any idea ?

Regards,

Clément

Hi,

Have you tried Wait BOOT ? If not, please try that and let us know if that solves the issue.

Regards,

Vivek Singh

Hi,

No I haven't as it's not so simple to change the configuration.

In the end I need my board to boot from Flash so I don't clearly understand why you want me to change the configuration to Wait boot ?

Regards,

Clément

I am assuming you have security enable on this device (based on snapshot of USER OTP you posted earlier). If yes, then you need to have WaitBOOT to be able to connect the debugger to device for debug.

Regards,

Vivek Singh

A fresh device would have security enabled ?

I am a bit surprised by that as we never did anything to lock the device.

Clément

No, fresh device will not be secure but there are some security initialization needed to enable access to the resources on the device.

Please try WaitBOOT and see if that fixes the issue. Also can you probe the XRSn pin on this board and see if it behaves same way as on working boards?

Regards

Vivek Singh

Thanks for your answer, I'll try that later this week or next one, as we just had a second board on which we encounter the issue (clean new board as well).

If Wait boot works I can go back to boot from flash aeterwards ?

Clément

Vivek Singh, the boot mode is set with 0201 resistor and are not the default ones as on both boards the OTP was programmed and some SW loaded at least once.

As you can imagine unsoldering those resistors to change them from 1/1 to 1/0 is quite uneasy, we don't have the equipment internally and would need to go through a supplier of us to perform the operation.

Before we engage anything, can you explain me why we would need to go from boot to flash to wait boot ?

And as said above, we would need to revert it back I guess once we fix it (if fixing is the right word) ?

That wouldn't explain though why first the CPU would have that odd behavior, then could be programmed once and changed back to that odd behavior.

Also on the other unit on which we just encountered the issue today, it worked for the first programming then went into that odd behavior.

Regards,

Clément

Hi

Clément Letonnelier said:

Vivek Singh, the boot mode is set with 0201 resistor and are not the default ones as on both boards the OTP was programmed and some SW loaded at least once.

I am a bit confused now. Earlier you mentioned that it's fresh device but now you are saying OTP was programmed on these device. What was programmed in OTP ?

Regards,

Vivek Singh

Hi,

For you to understand, a little summary of the steps:

1/ We had the issue at first on the fresh device when we started discussing together the problem.

2/ Then we were able - out of magical - to perform a load of our software along with the OTP programming, which is when you told me to contact you again whenever the problem happens.

3/ After some time, it started to get hectic again and this is when I reopened the discussion.

We programmed in the OTP the GPIO to be taken into account for the boot mode as we aren't using the default ones.

In between steps 2 and 3, we managed to load software onto the CPU1 multiple times (software that do not deal with the OTP).

Best regards,

Clément

Ok, understood. Now, on the device where you have programmed the OTP to change the default BOOT pins, after connecting to CCS, can you check value of ERR_STATUS register inside Flash0EccRegs register structure. You can check this via CCA register view.

Regards,

Vivek Singh

Hello Vivek,

I have checked, the register is equal to 0, no errors.

Clément

Can you try below -

After connecting to CCS, issue the CPU reset from CCS and then click on "Run" and when CPU halts, try to load the code again.

Also if you have any FAE assigned to your account, please let me know his/her name.

Regards,

Vivek Singh

I will try that on monday.

Our FAE related to CPU topics is Robert Finger.

Regards,

Clément

Ok, thank you.

Hello Vivek,

So I did what you stated:

1/ Connect to target without loading

2/ Reset CPU from debug view

3/ Run and wait till CPU halts

4/ Load SW

Note that for step 3, the CPU didn't halt, I had to pause execution.

The error I get when loading at that point is the same:

C28xx_CPU1: GEL Output:
Memory Map Initialization Complete
C28xx_CPU1: Flash Programmer: Warning: The configured device (TMS320F28377D), does not match the detected device (). Flash Programming operations could be affected. Please consider modifying your target configuration file.
Texas Instruments XDS2xx USB Debug Probe_0/C28xx_CPU2 : Target must be connected before loading program.
C28xx_CPU1: Warning: Failed unlocking device (zone 1) after reset.
C28xx_CPU1: Warning: Failed unlocking device (zone 2) after reset.
C28xx_CPU1: Trouble Setting Breakpoint with the Action "Remain Halted" at 0xc0eb: (Error -1066 @ 0xC0EB) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 8.0.27.9)
C28xx_CPU1: Breakpoint Manager: Retrying with a AET breakpoint
C28xx_CPU1: Error occurred during flash operation: Timed out waiting for target to halt while executing wr_pll.alg
C28xx_CPU1: Error writing the PLL values (Flash algorithm timed out). Operation cancelled.
C28xx_CPU1: Perform a debugger reset and execute the Boot-ROM code (click on the RESUME button in CCS debug window) before erasing/loading the Flash. If that does not help to perform a successful Flash erase/load, check the Reset cause (RESC) register, NMI shadow flag (NMISHDFLG) register and the Boot-ROM status register for further debug.
C28xx_CPU1: Breakpoint Manager: Unable to remove requested AET job
C28xx_CPU1: File Loader: Memory write failed: Unknown error
C28xx_CPU1: GEL: File: C:\Users\Servo\Desktop\workspace_v8\RECETTE_DUAL_MON\MON_FLASH_HWV2\RECETTE_DUAL_MON.out: Load failed.
C28xx_CPU1: Trouble Setting Breakpoint with the Action "Remain Halted" at 0xc056: (Error -1066 @ 0xC056) Unable to set/clear requested breakpoint. Verify that the breakpoint address is in valid memory. (Emulation package 8.0.27.9)
C28xx_CPU1: Breakpoint Manager: Retrying with a AET breakpoint

Regards,

Clément

Ok. Robert will contact for offline discussion on this.