Why does SESR in BF512 hang?

I am trying to port a Lockbox application from BF547 to BF512. I faced a problem with SESR: it seems to hang within Secure Entry Mode.

After a   raise 2 assembler instruction is issued, the next instruction is never executed. The same code works fine on BF547: even if autentication fails the execution continues past   raise 2 instruction.

The SESR argument buffer and EVT2 vector are initialised, all interrupts are masked, memory locations seem to be correct. I tried different SESR call contexts, both in C and assembler. When called from C, a workaround for anomality 05000405 was applied - with no effect. I also tried to damage the signature to force SESR to complete with an error - also doesn't help.

For clear check, I used a VDSP++ Lockbox example for BF548. It works fine on BF547, but once ported to BF512, it hangs. However, if I remove   raise 2 instruction (and SESR obviously is not called), the post-SESR portion of code is executed. I think it means that once SESR is called it never returns.

Same situation was checked on pre-production samples of BF518 version 0.1 - the result is the same.

Are there any reasons for SESR to hang? Maybe, there is some Lockbox sample code for BF51x? Are there any special issues concerning Lockbox implemetation in BF51x (exept those documented in Silicone Anomality List)?

Peter Minin

  • 0
    •  Analog Employees 
    on Jan 29, 2011 2:22 AM over 10 years ago

    Hi Peter,

    Just to confirm, what is EVT2 set to when you execute a "raise 2;"?

    Also, what does your secure code do?  Can you verify that you're not getting hung in your secure code?

    Regards,

    Gabby

  • Hi Gabby,

    the EVT2 vector is 0xffa14000 - exactly as specified in the "ADSP-BF51x Blackfin Processor Hardware Reference" page 24-32. By the way, this address in BF512 is not readable, neither with processor instruction nor with MDMA access. The whole area starting from 0xffa14000 is specified as "Reserved" in Hardware Reference.

    To the contrast, in BF547 one can read it with MDMA, and there is a workable code that looks like this:

    [FFA14000]     JUMP.L 128

    [FFA14004]     JUMP.L 20340

    [FFA14008]     JUMP.L 20456

    [FFA1400C]     JUMP.L 20268

    [FFA14010]     JUMP.L 20122

    [FFA14014]     JUMP.L 35292

    [FFA14018]     JUMP.L 37480

    [FFA1401C]     JUMP.L 37644

    Could it be that BF51x contains no SESR code (at least at specified location)?

    I shrunk my secure function to just switching on a single LED. It is a linear code, and it doesn't hang on BF547.

    Best regards,

    Peter

  • 0
    •  Analog Employees 
    on Jan 31, 2011 8:01 PM over 10 years ago

    Hi Peter,

    I see what the problem is.  The documentation is incorrect.  The SESR resides in different locations for different parts.  Please set the EVT2 vector to BFROM_SECURE_ENTRY which is an entry into a jump table which will jump to the SESR.  This macro is found in bfrom.h which is included in the VDSP++.

    Regards,

    Gabby

  • Hi Gabby,

    BFROM_SECURE_ENTRY seems to work, though it is never used in VDSP++ Lockbox examples, neither it is commented. This vector is 0xEF000014 for all Blackfin-enabled chips and as I understand should perform a jump to device-specific location.

    For BF51x it redirects to 0xFE001000. I believe 0xFE001000 should have been printed on page 24-32 of "ADSP-BF51x Blackfin Processor Hardware Reference", as well as on page 16-33 of "ADSP-BF52x Blackfin Processor Hardware Reference", instead of misleading 0xFFA14000. The address 0xFE001000 is used in BF52x Lockbox example directly, without referencing BFROM_SECURE_ENTRY.

    I wish this documentation error be corrected as quickly as possible, because it leaves BF51x user completely unarmed - there is no Lockbox examle for BF51x, and BFROM_SECURE_ENTRY is never mentioned in documentation or commented (even in the Internet). I was lucky because I had a working BF547 Lockbox project, and at least was sure that my secure function is OK. Solving this problem from the scratch would have been virtually impossible.

    Best regards,

    Peter

  • 0
    •  Analog Employees 
    on Feb 1, 2011 9:33 PM over 10 years ago

    Hi Peter,

    The errors with the documentation have been logged and will be fixed for the next version of the documentation.

    Regards,

    Gabby