Post Go back to editing

reading factory serial number

Category: Software
Product Number: ADSP-BF704

Hi,

I am trying to read the factory serial number by

  result=adi_rom_otpfsnget(otpfsncmd_fsn, data);

However I get an exeption:

A non-recoverable error or exception has occurred.
  Description:   Attempted to use a Supervisor register or instruction from User mode (Exception with EXCAUSE=0x2E).
  General Type:  UnhandledException
  Specific Type: SupervisorResource
  Error PC:      0x04003ad2

I _am_ already in supervisor mode, so what is the correct procedure to read fsn from OTP?

  • Hi Julian,

    We tried to reproduce the issue on the ADSP-BF707 EZ-KIT, but were unable to replicate it.

    To assist you further, could you please provide more information on the following points.
    1) Can you please share the CCES version and the silicon revision of the part you're using? If you are using an older version of CCES, please try updating to the latest version(2.12.0) and check if the issue persists.
    2) Can you confirm if the part has been locked? If so, please be aware of anomaly (19000061 - Factory Serial Number Cannot Be Read When Device Is Locked). For further details, please refer to anomaly 19000061 (Page 12/13) in the link provided below.
    Https://www.analog.com/media/en/dsp-documentation/integrated-circuit-anomalies/ADSP-BF700_701_702_703_704_705_706_707-Blackfin-Anomaly-List.pdf

    Regards,
    Nandini C

  • Hi Nandini,

    CCES VErsion is 2.12.0.0
    Since I have not programmed anything into OTP I assume the device is unlocked.  What is the exact definition of "unlocked device"?
    Silicon revision is 1.1


    I am simply calling:

     result=adi_rom_otpfsnget(otpfsncmd_fsn, data);

    This is executed from an interrupt context.

    Looking a bit more detailed into what happens reveals:

    System state before function call:
    SMPU is disabled
    SYSCFG    = 00000306    
    IPEND    = 00008801    

    adi_rom_otpfsnget:
    08006338:   LINK 0xc;
    0800633c:   [FP+0xc]=R1;
    0800633e:   [FP+0x8]=R0;
    08006340:   R2=0x400004c;
    08006348:   [FP+0x10]=R2;
    0800634a:   P1=R2;
    0800634c:   CALL(P1); -> call to address 0x400004c with r0=0x13,
    0800634e:   R0=R0.B(Z);
    08006350:   UNLINK;
    08006354:   RTS;


    04003aa8:   LINK 0xc;
    04003aac:   P0=R0;
    04003aae:   CALL.L -0x1e;
    04003ab2:   R0=0x38000000;
    04003aba:   CC=R2<=0x0;
    04003abc:   R0=R1+R0;
    04003abe:   IF CC JUMP 0x22;
    04003ac0:   P1=R0;
    04003ac2:   R0=0x0(X);
    04003ac4:   LSETUP(0x14)LC0=0xffffffff;
    04003ac8:   R1=R0.B(Z);
    04003aca:   P2=R1;
    04003acc:   R0+=0x1;
    04003ace:   R1=R0.B(Z);
    04003ad0:   CC=R1<R2;
    04003ad2:   R1=[P1++];  -> this instuction causes the exception with P1= 38000380     which should be the fsn OTP address
    04003ad4:   P2=P0+(P2<<2);
    04003ad6:   [P2]=R1;
    04003ad8:   IF!CC JUMP 0x8;
    04003ada:   JUMP.S -0x16;



  • After exception looking at the CPLB registers:

    SEQSTAT    0000002E    Sequencer Status Register

    L1DM_DCPLB_ADDR0    08000000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR1    08040000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR2    08050000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR3    08060000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR4    08070000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR5    04000000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR6    04040000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR7    70000000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR8    70001000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR9    74000000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR10    74001000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR11    40000000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR12    44000000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR13    38000000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR14    00000000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_ADDR15    00000000    L1DM Data Memory CPLB Address Registers
    L1DM_DCPLB_DATA0    0004109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA1    0003109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA2    0003109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA3    0003109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA4    0003009D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA5    0004109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA6    0004109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA7    0001109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA8    0001109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA9    0001109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA10    0001109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA11    0008109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA12    0008109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA13    0001109D    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA14    00000000    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DATA15    00000000    L1DM Data Memory CPLB Data Registers
    L1DM_DCPLB_DFLT      00000F00    L1DM Data Memory CPLB Default Settings Register
    L1DM_DCPLB_FAULT_ADDR    38000380    L1DM Data Memory CPLB Fault Address Register
    L1DM_DCTL            00000207    L1DM Data Memory Control Register
    L1DM_DPERR_STAT      00000000    L1DM Data Memory Parity Error Status Register
    L1DM_DSTAT          00020000    L1DM Data Memory CPLB Status Register
    L1DM_SRAM_BASE_ADDR    11800000    L1DM SRAM Base Address Register

    -> FAULT_ADDR    is 38000380 as expected, DSTAT = 00020000 tells supervisor mode, but the FAULT field is 0: seems strange as it should be pointing to L1DM_DCPLB_ADDR13 though.
    The DCPLB regs were all configured by CCES startup code.

    I am not sure if OPT access is cachable, so disabled cache in debugger for OTP memory (L1DM_DCPLB_DATA13    = 0001009D    )

    -> no more exception! If that is an error in the CCES software package, it should be fixed. I could not figure out where CCES takes the CPLB entries from. I assumed
    c:/Analog Devices/CrossCore Embedded Studio 2.12.0/Blackfin/lib/src/libc/crt/cplbtab704.s but that does not fit the entries in my code.
    The  startup code generator puts the cplb table in app_cplbtab.c

    For a fix I just edited app_cplbtab.c to set the the OPT cplb entry to CPLB_DNOCACHE.

    However, not sure if that is the inteded final fix?!

  • Hi Julian,

    Thank you for sharing more information.

    As mentioned in the HRM (Page No: 487/2223), "OTP memory does not support burst transfers, which are required to support cache line fills. As such, OTP memory should not be covered by a cache-enabled DCPLB. If it is, the OTP controller returns an error when a read access is attempted". The link for the HRM manual is given below.
    https://www.analog.com/media/en/dsp-documentation/processor-manuals/BF70x_BlackfinProcessorHardwareReference.pdf

    Hence, the data cache needs to be disabled. Can you please check the "Cache Configuration" in the "system.svc" and disable the data cache if it is enabled.

    Regards,
    Nandini C

  • Hi Nandini,

    the data cache is enabled in the system.svc as my project will need the cache. Since the OTP memory access always requires it to be disabled I would have expected the the code generater would automatically exclude OPT from the cache. This is not the case, though.

    so I see 2 options:

    - disable the cache globally during runtime before OTP access and re-enable it after (causes overhead and runtime penality)

    - have the cache enables but exclude OTP memory from caching by configuring the CPLB table accordingly.

    I used the latter approach to have it work. This actually could/should be done by CCES startup code generator as the CPLB table gets generated dependent on the settings made in system.svc. The OTP memory section already gets its own CPLB entry generated, but with incorrect chaching setting So I consider this as a CCES code generator flaw. It can be fixed by manually modifiying app_cplbtab.c after generation.

    Regards,

    Julian

  • Hi Julian,

    Thank you for the suggestion. We will make a note of it and pass this to the appropriate team.

    Regards,
    Nandini C