TMDSCNCD28069MISO: file load error

Dave Reagan

Part Number: TMDSCNCD28069MISO
Other Parts Discussed in Thread: MOTORWARE, TMS320F28069F, TMDSCNCD28069ISO

Hello C2000 Forum,

I have a DRV8301-69M Evaluation kit, purchased in order to evaluate your InstaSpin BLDC control method.
I managed to progress as far as lab05b. Then, when I tried switching from evaluating InstaSpin FOC to InstaSpin Motion, in order to run lab05c, I encountered the following error pop up:

   Launching Debug Session

   Load program Error.

   File:
   C:\ti\motorware\motorware_1_01_00_18\sw\solutions\instaspin_foc\boards\drv8301k
   it_revD\f28x\f2806xF\projects\ccs\proj_lab02c\Release\proj_lab02c.out: a data
   verification error occurred, file load failed.

I looked for a solution here in the forum, and found a helpful one (I think).

The respondent asked the original poster to look at memory locations 0x3f7ff8 - 0x3f7fff.
Just as the person in the post, I have all zeroes in those locations, the implication being that the device is "locked" and I can't program it.
The respondent suggested a look at another post for a possible solution, but it will not work for me.
In that post, however, David Alter made it sound as though this were sort of a random error, and no fault of the user.

   Hello Kirankumar,

       If you don't know the values the password locations contain, and you don't already have the ERASE algorithm in secure memory, you cannot get back in to the device.

       The password locations are part of flash sector A. They get cleared to 0's and then set back to 1's when you erase flash sector A. If something happens during that
       process (e.g., power loss, or sometime hiccup in the debugger connection/setup) the passwords can get corrupt. It does happen sometimes, and users generally
       do not know what or when it happened.

       Sorry.

   David

   P.S. On the latest C2000 devices (e.g, F2805x, F2837x), the password locations are located in OTP memory instead of flash. That will avoid the possibility of password
   corruption when working with the flash.

   -----------------------------
   David M. Alter
   Senior Member Technical Staff
   Texas Instruments Inc.

Should I get another F28069 ISO Control Card (Part # TMDSCNCD28069MISO)? And, since this is something that just "happens sometimes", can I get it at no charge?
Thank You, and

Best Regards,

Dave Reagan

over 6 years ago

0 Manoj Santha Mohan over 6 years ago

TI__Guru 55700 points

Dave,

It looks like you might have inadvertently locked the device. This can happen when you interrupt flash erase function / flash program function when it is in middle of the algorithm. If you know the password, you can try unlocking it. But, if you are not sure, your only option is to buy another control card. TI doesn't replace these cards for free.

Regawrds,
Manoj

0 Dave Reagan over 6 years ago in reply to Manoj Santha Mohan

Intellectual 800 points

Hi Manoj,

Thanks for the prompt reply. Ok - so I have to buy a new card. How can I ensure that this absolutely never happens again? Because, if this just "happens sometimes", and there is no way around it, I don't think we could afford to put a TMS320F28069F in any of our products.

Thanks,

Dave

0 ChrisClearman over 6 years ago in reply to Dave Reagan

TI__Guru** 119670 points

it doesn't just happen sometimes. If the flash is being programmed / erased and there is a power glitch then it may be disrupted leaving unknown values in the password location.

I've actually never had this occur

0 Dave Reagan over 6 years ago in reply to ChrisClearman

Intellectual 800 points

Hi Chris,
Well... I have. Just my luck. From what David Alter has written, it sounds like having an "ERASE algorithm in secure memory" and supplying a known password could prevent this from ever happening again. That's what I'm interested in - not encountering this again. Does that sound like the solution? If so, how do I do it?
Thanks,
Dave

0 Manoj Santha Mohan over 6 years ago in reply to Dave Reagan

TI__Guru 55700 points

Dave,

Yes, there is a possible solution.

If you execute Flash API algorithms from secure memory, you will still be able to erase the device in locked flash.

Here is the procedure:

1) Store Flash API in flash sector which you will never erase unless you completely re-program all the flash sectors.
2) Since you cannot execute flash API algorithm from flash, you need to copy these Flash API functions into RAM. In your case, you need to copy these functions to secure RAM
3) When you are executing Flash API algorithms from secure RAM, you don't need to unlock the device.
4) Once you know if you have inadvertenly locked the device, you can invoke flash erase operation on SectorA to recover the device

Unfortunately, we don't have ready-made example to share which showcases the above procedure. So, you may have to develop this yourselves.

Regards,
Manoj

0 Dave Reagan over 6 years ago in reply to Manoj Santha Mohan

Intellectual 800 points

Hi Manoj,

So I got another F28069 ISO Control Card (Part # TMDSCNCD28069MISO). I'm trying to run lab02c, just to check out the card, and whether it's operating correctly.

When I go into debug, I get the following message:

Trouble Reading Register PC:
(Error -1142 @ 0x0)
Device blocked debug access because it is currently executing non-debuggable code. Choose 'Rude Retry' to disable polite mode and force the operation.
(Emulation package 8.1.0.00005)

I've followed the suggestion and clicked on Rude Retry. Hit the "Run" button, and literally nothing happens...

Every time I pause the execution, it's stuck on the "endless hold loop" in this interrupt:

interrupt void PIE_illegalIsr(void)
{

// The next two lines are placeholders
asm(" ESTOP0");

// endless hold loop
for(;;);

} // end of PIE_illegalIsr() function

What's going on?

Thanks,

Dave Reagan

0 Dave Reagan over 6 years ago in reply to Dave Reagan

Intellectual 800 points

I discovered what was wrong. I ordered the wrong part. On Mouser's site, I did a search for TMDSCNCD28069MISO. Two results came back, one cheaper than the other. I, of course, ordered the less expensive one, thinking that the price difference must be packaging or something (there was even a comment "alternative packaging" associated with the part). Anyway, the part I ordered was TMDSCNCD28069ISO, which, in my opinion, should not have appeared, since I did a specific search for a specific part number. So I've gotta wait some more...