UniFlash : [ERROR] C28xx_CPU2: Error setting the GSxMSEL register for Flash operations

Hello,

Kier said:

[21/01/2022 10:00:14] [ERROR] C28xx_CPU2: Error setting the GSxMSEL register for Flash operations

I've seen this issue in the past. It was typically caused when you are only connected to CPU2 and try to flash it:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/718227/launchxl-f28379d-unable-to-download-cpu2-flash

The workaround was to connect to CPU1 first, then CPU2.

Current versions of the tools (CCS and UniFlash) should have it so that when connecting to CPU2 first, the tool would then auto-connect CPU1 first before finishing the connect to CPU2. 

Since you are using UniFlash 7 (which is the current version), I'm not sure why you are getting this issue. I am unable to reproduce the issue.

When you flash the device, do you first flash CPU1 and then CPU2 in the same session? Or are you only trying to flash CPU2 in the session? If it is the latter, can you try flashing CPU1 first (and make sure CPU1 remains connected) and then CPU2 right after and see if that works?

Thanks

ki

Thanks for the reply.

I'm flashing both CPUs in the session as follows:

- Load Session file.

- Click Load Image CPU1

- Select Program CPU2 tab

- Click Load Image CPU2

The setting in the top right corner appears as follows and this seems to be in keeping with your advice.

However if I deselect "Remain Connected"...

....the problem disappears which is counterintuitive so I'm not sure why this works. Can you enlighten me please?

Unfortunately this setting doesn't seem to be in the session file so I can't control it for end users.

The other oddity is that the dots next to the CPU in the screenshot are always grey. I thought these glowed green when connected, is that correct?

Hi Kier,

Does your CPU1 application configure GSxLOCK register?

Thanks and regards,
Vamsi

Hi Vamsi,

Thank you but my application doesn't do anything with those registers.

The problem appears to be with UniFlash. When the "Remain Connected" check box is selected I get the error. When it is not selected there is no error. The question is why that should be.

Kier.

Hi Kier,

Thank you for the information.

We will discuss internally and get back to you.

For now, please continue with the configuration that worked for you.

Thanks and regards,
Vamsi

Kier,

Can you enable DS logging and reproduce the issue? Then zip the log and attach it to this thread.

More more details on DS logging, please see:

https://software-dl.ti.com/ccs/esd/uniflash/docs/v7_0/uniflash_quick_start_guide.html#defect-reporting-and-logging

Also, would it be possible to share the files being flashed on both CPUs?

Thanks

ki

Kier said:

The other oddity is that the dots next to the CPU in the screenshot are always grey. I thought these glowed green when connected, is that correct?

yes, it should. A bug has been filed for this. Tracking link: https://sir.ext.ti.com/jira/browse/EXT_EP-10734

Thanks

ki

2630.ds.zip

Thanks Ki. Log uploaded.

Coming back to Vamsi's question, actually my application does give CPU2 master control over some GSRAM blocks but it doesn't lock any configuration. However, I would have thought that the debugger emulator resets the CPUs when it connects such that MSEL regsiters go back to their defaults. Thought I'd mention it in case it helps.

Kier.

Kier,

As long as your application does not lock it, plugin should be able to write to GSxMSEL.  Our team is trying to reproduce this issue - as of now, they are able to program successfully.  

Thank you for the logs - Ki's team will review and get back to you.

Thanks and regards,
Vamsi

Kier - just a quick update that we are still investigating the issue. We will inform you fo an updates as we get them.

Thanks

ki

Kier,

Just for an experiment: In your CPU1 application code, instead of writing 0x67C0 in GSxMSEL, can you try writing 0x7C0 and see if that eliminates the error?  That helps us to confirm our observation and proceed for a fix.  Thank you.

Best regards,
Vamsi

Hello Vamsi,

So you mean don't give CPU2 control of GS13 and GS14? If so, I tried that but it doesn't improve matters.

However, if I remove all of the following lines then yes, the problem does go away. Bear in mind I had to modify other parts of CPU2 application so that it no longer tried to write to these areas to stop it falling over.

    /* Give permanent control of these blocks to CPU2. */
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS6,  MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS7,  MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS8,  MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS9,  MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS10, MEMCFG_GSRAMMASTER_CPU2 );

    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS13, MEMCFG_GSRAMMASTER_CPU2 );
    MemCfg_setGSRAMMasterSel( MEMCFG_SECT_GS14, MEMCFG_GSRAMMASTER_CPU2 );

Does that help?

Kier,

Thank you for the experiment.  That helps us to analyze further.  We will get back to you.

Best regards,
Vamsi