2011-10-11 03:18:06     CORE B: error message type

Document created by Aaronwu Employee on Aug 27, 2013
Version 1Show Document
  • View in full screen mode

2011-10-11 03:18:06     CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103777   




I was loading the icc core as usual:


./icc_loader -l icc


This is a build of icc core and icc_loader from the latest svn update.


Normally it works fine but this time I've got an error when starting the session:




root:/> dhcpcd &                                                              

[1] 279 dhcpcd                                                                

root:/> smc91x smc91x.0: eth0: link down                                      

smc91x smc91x.0: eth0: link up, 100Mbps, full-duplex, lpa 0x45E1              


root:/> tftp -g -r icc                                             

root:/> tftp -g -r icc_loader                                      

root:/> tftp -g -r test_ad1836_driver                              

root:/> chmod 777 icc_loader                                                  

root:/> ./icc_loader -l icc                                                   

writing to 0xfeb00000, 0x6934    bytes: OK                                    

writing to 0xff600000, 0xc4      bytes: OK                                    

root:/> COREB: @@@ gen pool create0                                           

COREB: @@@ gen pool create1                                                   

COREB: session table 3d00000                                                  

COREB: error messag type d3451993e                                            

COREB: error messag type dcf6ffc8e                                            

COREB: error messag type 67a98aace                                            

COREB: error messag type cf8aeb89e




Looking at the icc core this is triggered when the session id not valid:


        session = sm_index_to_session(index);

        if (!session) {

                coreb_msg("error messag type %08xe\n", msg->type);

                sm_message_dequeue(cpu, msg);






Which mean the the session index = 0 returned by:




struct sm_session* sm_index_to_session(sm_uint32_t session_idx)


    struct sm_session *session;

        struct sm_session_table *table = coreb_info.icc_info.sessions_table;

        if (session_idx < 0 && session_idx >= MAX_SESSIONS)

                return NULL;

    if (!test_bit(session_idx, table->bits))

                return NULL;

        session = &table->sessions[session_idx];

        return session;





Why do I get this error, how do I fix it











2011-10-11 04:02:50     Re: CORE B: error message type

steven miao (CHINA)

Message: 103785   


Hi William,


this error means it received unexpected message from L2 message queue, maybe some other program overwrite the L2 message queue(hdcpd or networking driver)






2011-10-11 04:28:42     Re: CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103786   


Hi Steven,




What is the best way to stop my network driver.




Why this wasn't the case before, is the new icc version have a diferent memory structure than previously?












2011-10-11 04:30:53     Re: CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103787   


as well, how can I make work my network driver in the same time as the icc multicore processes?




Is there is any tools I can use to debug and track those type of memory conflict?










2011-10-11 04:40:33     Re: CORE B: error message type

steven miao (CHINA)

Message: 103788   


Hi William,


can you try make clean icc_core and rebuild it, the L2 message address is 0xFEB18000, you can check this memory region


with jtag tool.




btw, did you disable L2 cache in kernel config










2011-10-11 06:03:29     Re: CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103789   


Hi Steven,


I did do a make clean of icc_core


I did disable L2 cache in the kernel config, here is the screen shot of my config to make sure (I'm using a previous kernel version thoughof a month and half old already load in my dev board):


      *** Cache Support ***                                        │ │

  │ │    [*] Enable ICACHE                                                │ │

  │ │    [*]   Enable ICACHE for external memory                          │ │

  │ │    [ ]   Enable ICACHE for L2 SRAM                                  │ │

  │ │    [*] Enable DCACHE                                                │ │

  │ │    [ ]   Enable only 16k BankA DCACHE - BankB is SRAM               │ │

  │ │    [*]   Enable DCACHE for external memory                          │ │

  │ │            External memory DCACHE policy (Write through)  --->      │ │

  │ │    [ ]   Enable DCACHE for L2 SRAM 


I have as well icc protocole enable:


--- icc driver                                                   │ │

  │ │    [*]   icc protocol




Just have seen an new option (icc_debug) I'm using the kernel version on my board:


Linux version 3.0.0-ADI-2011R1-pre-svn10064


in the kernel load I get:




Blackfin L1 Data A SRAM: 16 KB (16 KB free)                                   

Blackfin L1 Data B SRAM: 16 KB (16 KB free)                                   

Blackfin L1 Instruction SRAM: 16 KB (3 KB free)                               

Blackfin L2 SRAM: 128 KB (128 KB free)


Instruction Cache Enabled for CPU0                                            

  External memory: cacheable in instruction cache                             

  L2 SRAM        : uncacheable in instruction cache                           

Data Cache Enabled for CPU0                                                   

  External memory: cacheable (write-through) in data cache                    

  L2 SRAM        : uncacheable in data cache 


Memory map:                                                                   

  fixedcode = 0x00000400-0x00000490                                           

  text      = 0x00001000-0x00157830                                           

  rodata    = 0x00157830-0x001dd0a8                                           

  bss       = 0x001de000-0x001ee760                                           

  data      = 0x001ee760-0x00208000                                           

    stack   = 0x00206000-0x00208000                                           

  init      = 0x00208000-0x008ae000                                           

  available = 0x008ae000-0x03800000                                           

  DMA Zone  = 0x03f00000-0x04000000




When I kill dhcpd after upload of the icc and icc_loader via tftp I still have the same error.


is there is another program to kill for the ethernet driver?




I'v connect to my JTAG and run :


bfin-gdbproxy bfin


in one screen on my pc and




in the other, but I'm not sur how to link to the kernel program or check the memory map. could you give me the set of instruction to do so.












2011-10-11 06:30:04     Re: CORE B: error message type

steven miao (CHINA)

Message: 103790   


Hi William,


I tried the lastest kernel and icc_utils, this error didn't appears, I also used ethernet and tftp to load the images, so it wasn't caused by ethernet. Can you update your kernel to the lastest revision, and rebuild both kernel and icc(icc depends on kernel), the kernel should match with the icc.


If you want to use jtag debugger


1. bfin-gdbproxy bfin


2. bfin-elf-gdb


3. in gdb console, attach the targe board with "target remote :2000"


then you can check the memory by "x/64  0xFEB18000"




for details pls ref:










2011-10-11 09:03:13     Re: CORE B: error message type

william pagnon (AUSTRALIA)

Message: 103792   


Hi Steven,




Yes that was it, my uCLinux kernel version was too old,


./icc_loader -l icc does load propely the core icc in the core B


However I have another problem now that must be related to my code (tell me if you prefer I create a new thread)


I've created a bare metal version of FreeRTOS converted from the VDSP version So I can run FreeRTOS under the Core B for my real time DSP operations.


so when I load my basic compiled application of FreeRTOS on core B I've got :


COREB: execption 26 addr 3c0045c                                              

COREB: execption 24 addr 3c0045c


I've look in the icc core code and it seem to be code by the assembler file via the function dump_execption:



        [--sp] = SYSCFG;                                                      

        [--sp] = P0;        /*orig_p0*/                                       

        [--sp] = R0;        /*orig_r0*/                                       

        [--sp] = (R7:0,P5:0);                                                 


        P0.H = HI(0xFEB1FFFC);                                                

        P0.L = LO(0xFEB1FFFC);                                                


        r0 = SEQSTAT;                                                         

        r0 <<= 26;


        r0 >>= 26;                                                            

        r1 = retx;                                                            

        call _dump_execption;                                                 

        [P0] = r0;                                                            


        (R7:0,P5:0) = [SP++];                                                 

        sp += 8;        /* Skip orig_r0/orig_p0 */                            


        SYSCFG = [sp++];                                                      








Could you tell me what would be the reason that could trigger such error?


Looking at the processor doc, this is trigger due to a core exception (EVT3), what could trigger a core exception?




Thanks again for your help








2011-10-11 22:05:53     Re: CORE B: error message type

steven miao (CHINA)

Message: 103797   


Hi William,


so you want to load freertos to coreB, how did you compile and link the freertos? And what is the file format of freertos image, is it a ELF format?


I've put a dum_exception function to dump exception cause code, you can ref "Program Sequencer" section of bf561 hrm for details, code 24 means Attempted misaligned data memory or data cache access while code 26 means Used by the MMU to signal a CPLB miss on a data access and the fault address is 0x3c0045c, you can check the code there might be a bad address around.








2011-10-11 23:31:19     Re: CORE B: error message type

Sonic Zhang (CHINA)

Message: 103799   


Yes, please create new thread for new questions.