CORE B: free RTOS implementation issue COREB: execption(2011-10-12)

2011-10-12 01:52:56     CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103800   

Hi this is the questions started in a previous thread.

I put the history of it here and will continue from there:

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:

ENTRY(_evt_evt3)

        [--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 */                            

        csync;                                                                

        SYSCFG = [sp++];                                                      

        csync;           

        rtx;                                                                  

ENDPROC(_evt_evt3)

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

William

QuoteReplyEditDelete

2011-10-12 12: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.

-steven

QuoteReplyEditDelete

2011-10-12 13:31:19     Re: CORE B: error message type

Sonic Zhang (CHINA)

Message: 103799    

Yes, please create new thread for new questions.

QuoteReplyEditDelete

2011-10-12 03:22:15     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103804   

Hi Steven,

I tried to use your memory map script to implement to free RTOS. Basically, I've used my previous icc successfull test of the AD1836 driver I convert from VDSP and add to it Free RTOS. It is the mess at the moment as I was just want to do a validity test before to structure properly my project. So it is a bit of a copy past from your task example to my led test, to my AD1836 driver to my FreeRTOS test.... So  have a lot of

So the initial free RTOS version is in the VDSP format and I conterted it to ELF blackfin bare metal format, changing the interuption handler and other pragma. I had some issues with linking error due to long call frome Assembler code to C code that I resolved by putting the problematic assembler code in the section .text

you can see the details of this issue on the following post:

https://blackfin.uclinux.org/gf/project/toolchain/forum/?_forum_action=ForumMessageBrowse&thread_id=46632&action=ForumBrowse&forum_id=44&feedback=Message+replied.

the FreeRTOS version I used to convert to bfin-elf can be found here:

  sourceforge.net/projects/freertos/files/OldFiles/

I attach my Makefile so you can see how I did compile and link Free RTOS with.

As well I attach some of the code files in case you want to have a look at some part of the code

Thanks a lot

William

app_c.c

user_isr.asm

ezkit_561.c

test_ad1836_driver.c

Makefile

QuoteReplyEditDelete

2011-10-12 04:33:17     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 103809   

Hi William,

can you paste the log of "./icc_loader -l icc " and "./icc_loader -f -e test_ad1836_driver" ?

since you test app actually is ad1836_driver + freertos and link to libc, it could be a little different from bare icc task case.

And you can try "bfin-uclinx-addr2line -f -e  test_ad1836_driver 0x3c0045c" to find out which code line cause the exception.

-steven

QuoteReplyEditDelete

2011-10-12 08:23:59     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103811   

Hi Steven,

here is the log file of the icc core and freeRTOS application start.

bfin-uclinx-addr2line -f -e  test_ad1836_driver 0x3c0045c is really usefull, thanks for letting me know. I'v got as result:

bfin-uclinux-addr2line -f -e  test_ad1836_driver 0x3c0045c

xQueueGenericSendFromISR

/home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/Source/include/../queue.c:808

this corespond in the code queue.c of FreeRTOS core to this function:

signed portBASE_TYPE xQueueGenericSendFromISR( xQueueHandle pxQueue, const void\

* const pvItemToQueue, signed portBASE_TYPE *pxHigherPriorityTaskWoken, portBA\

SE_TYPE xCopyPosition )

{

signed portBASE_TYPE xReturn;

unsigned portBASE_TYPE uxSavedInterruptStatus;

        configASSERT( pxQueue );

        configASSERT( pxHigherPriorityTaskWoken );

        configASSERT( !( ( pvItemToQueue == NULL ) && ( pxQueue->uxItemSize != \

( unsigned portBASE_TYPE ) 0U ) ) );

        /* Similar to xQueueGenericSend, except we don't block if there is no r\

oom                                                                           

        in the queue.  Also we don't directly wake a task that was blocked on a

        queue read, instead we return a flag to say whether a context switch is

        required or not (i.e. has a task with a higher priority than us been wo\

ken                                                                           

        by this post). */

        uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();

        {

                if( pxQueue->uxMessagesWaiting < pxQueue->uxLength )

                {

                        traceQUEUE_SEND_FROM_ISR( pxQueue );

                        prvCopyDataToQueue( pxQueue, pvItemToQueue, xCopyPositi\

on );

                        /* If the queue is locked we do not alter the event lis\

t.  This will                                                                 

                        be done when the queue is unlocked later. */

                        if( pxQueue->xTxLock == queueUNLOCKED )

                        {

                               if( listLIST_IS_EMPTY( &( pxQueue->xTasksWaitin\

gToReceive ) ) == pdFALSE )

                                {

                                        if( xTaskRemoveFromEventList( &( pxQueu\

e->xTasksWaitingToReceive ) ) != pdFALSE )

                                        {

                                                /* The task waiting has a highe\

r priority so record that a                                                   

                                                context switch is required. */

                                                *pxHigherPriorityTaskWoken = pd\

TRUE;

                                        }

                                }

                        }

                        else

                        {

                                /* Increment the lock count so the task that un\

locks the queue                                                               

                                knows that data was posted while it was locked.\

*/

                                ++( pxQueue->xTxLock );

                        }

                        xReturn = pdPASS;

                }

                else

                {

                        traceQUEUE_SEND_FROM_ISR_FAILED( pxQueue );

                        xReturn = errQUEUE_FULL;

                }

        }

        portCLEAR_INTERRUPT_MASK_FROM_ISR( uxSavedInterruptStatus );

        return xReturn;

}

I'm adding the whole file to the attachement.

As well I'm adding in my code some more debug print to see if I can localise where it trigger the problem. I let you know if it lead me anywhere.

I send you the binnary of the application as well in case it help.

Thanks

William

log_icc.txt

queue.c

test_ad1836_driver

QuoteReplyEditDelete

2011-10-12 08:59:25     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103812   

Hi Steven,

I did some additional testing, it seem to hapen at different time not related to the main program execution.

this time the excetion error started at

COREB: Enable DMA runned

COREB: create ep

COREB: create ep index 0 srcep 5

print before I do actually start the task to run...

I'm adding this new log so you can have a look. this time it complain about the address:

COREB: execption 24 addr 3c02822

when I do the addr2line I get:

bfin-uclinux-addr2line -f -e test_ad1836_driver 3c02822

icc_task_init

/home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/test_ad1836_driver.c:238

which corespond to:

session_index = sm_create_session(LOCAL_SESSION, SP_RES_MANAGER);

looking at protocol.c it seem to have trigger the exception this time here:

m_put_session_table();

in the int sm_create_session(sm_uint32_t src_ep, sm_uint32_t type)

after the print: coreb_msg("create ep index %d srcep %d\n", index, src_ep);

this time the problem is trigger at the icc session creation. Do you think there is a conflict betweek the task managed by icc and the task manage by freeRTOS?

Can we resolve that? What those 2 are trying to share? is it memory allocation or interutions vectors?

Thanks

William

log_icc_2.txt

QuoteReplyEditDelete

2011-10-12 23:04:37     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 103817   

Hi William,

Since SP_RES_MANAGER protocol hasn't implemented yet, can you try with SP_PACKET first as example task did firstly.  you can put the GPIO resource info into the packet buffer, with a quick glance at your code, I found you tried with packet protocol to send resource info buffer. If execption still happens, next step you can remove the task create and task scheduler to find out where the exception code actually is?

-steven

QuoteReplyEditDelete

2011-10-13 00:23:05     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103822   

Hi Steven,

I did change the code to SP_PACKET and put my resp object witht he GPIO info as the sent packet. hopefully I did it corecctly.

running this code give me as the result he file log_icc_3.txt

I still have the exception so I tried the other thing you suggested and commented task create and task scheduler. see log_icc_4.txt for the running print info

I still have the same address exception :  3c0045c

xQueueGenericSendFromISR

/home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/Source/include/../queue.c:808

Looking at the queue.808 code I'm not too sur what goaes wrong.

I attached the main c file and the binary with the latest changes.

Thanks

William

log_icc_3.txt

log_icc_4.txt

test_ad1836_driver.c

test_ad1836_driver

QuoteReplyEditDelete

2011-10-13 22:37:46     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 103852   

Hi William,

You could use jtag and gdb to backtrace the call stack who call xQueueGenericSendFromISR(). After you marked create_task and schedule task things, I couldn't find who called the xQueueGenericSendFromISR() function.

-steven

QuoteReplyEditDelete

2011-10-14 01:31:15     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103855   

Hi Steven,

I've try to do a back trace from the jtag gdb session, I'm not sure I did it right, please look at the prompt log bellow to see if it is what you suggested:

Remote debugging using :2000

[New Thread 1]

[New Thread 2]

0xffa00144 in ?? ()

(gdb) c

Continuing.

^C

Program received signal SIGINT, Interrupt.

0xffa00142 in ?? ()

(gdb) b 3c0045c

No symbol table is loaded.  Use the "file" command.

(gdb) c

Continuing.

^C

Program received signal SIGINT, Interrupt.

[Switching to Thread 2]

0xfeb00386 in ?? ()

(gdb) b 0x3c0045c

No symbol table is loaded.  Use the "file" command.

(gdb) bt 3c0045c

Invalid number "3c0045c".

(gdb) bt 0x3c0045c

#0  0xfeb00386 in ?? ()

(gdb) bt

#0  0xfeb00386 in ?? ()

(gdb) list

No symbol table is loaded.  Use the "file" command.

(gdb) x/64 0x3c0045c

0x3c0045c:    0xa3e8a3a9    0x18060981    0xe8016000    0x04840000

0x3c0046c:    0xe42a0010    0x0c020010    0xa1f81815    0x14260c00

0x3c0047c:    0xfeb0e14a    0xc203ce82    0x0000a0a8    0x03e4e10a

0x3c0048c:    0xa0a80062    0x0010e429    0xa0695008    0x0988b0a8

0x3c0049c:    0xa3a8142d    0xb3a86408    0x0012e428    0x18090c38

0x3c004ac:    0xe6286408    0xe8010012    0x60080000    0x00100484

0x3c004bc:    0x0c00a268    0x6008101e    0xe14a2fd1    0xce82feb0

0x3c004cc:    0xa0e8c203    0xe10a0000    0x006203e4    0x0010e428

0x3c004dc:    0xa0e84382    0x0002cc04    0x00009129    0x0988b0e8

0x3c004ec:    0xa06813d9    0xb0e85010    0x91282fd5    0x2fd2b0a8

0x3c004fc:    0xe14a6d25    0x304503c0    0x13c4e10a    0x0c000062

0x3c0050c:    0x60081fdb    0x2faa9320    0x322805fd    0xe8003019

0x3c0051c:    0x303a0003    0xa3e8a3a9    0x18060981    0xe8013007

0x3c0052c:    0x05bd0000    0xe42a0010    0x0c020010    0xe14a1814

0x3c0053c:    0xce82feb0    0xa0a8c203    0xe10a0000    0x006203e4

0x3c0054c:    0xe429a0a8    0x50080010    0xb0a8a069    0x1c030988

(gdb) load Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/test_ad1836_driver

Loading section .text, size 0x3660 lma 0x3c00000

Loading section .data_icc, size 0x4 lma 0x3c03660

Loading section .rodata, size 0x270 lma 0x3c03664

Loading section .data, size 0x70 lma 0x3c038d4

Start address 0xfeb00018, load size 14660

Transfer rate: 1116952 bits/sec, 3665 bytes/write.

(gdb) c

Continuing.

^C

Program received signal SIGINT, Interrupt.

0xfeb00136 in ?? ()

(gdb) bt

#0  0xfeb00136 in ?? ()

(gdb) c

Continuing.

bt

^C

Program received signal SIGINT, Interrupt.

0xfeb00136 in ?? ()

It seam to be stuck in 0xfeb00136 with no other backtrace link available. Looking at the doc, this address is a L2 SRAM address.

I tried a bfin-ulinux-addr2line on the icc core binnary and got:

bfin-uclinux-addr2line -f -e icc 0xfeb00136

__unknown_exception_occurred

/usr/src/packages/BUILD/blackfin-toolchain-2010R1/gcc-4.3/libgloss/bfin/basiccrt.S:418

I do not have this directory structure on my computer. I did a find command on the following directories:

uclinux-dist

/opt

/usr

Do you know what this structure is supose to refer to?

Let me know if I did the backtrace right

Thanks,

William

QuoteReplyEditDelete

2011-10-14 01:40:55     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103856   

As well I did a find on the whole project to see where xQueueGenericSendFromISR() is called.

this is the result:

find . -type f -exec grep -H 'xQueueGenericSendFromISR()' {} \;

./Source/include/queue.h: * This is a macro that calls xQueueGenericSendFromISR().

./Source/include/queue.h: * This is a macro that calls xQueueGenericSendFromISR().

./Source/include/queue.h: * This is a macro that calls xQueueGenericSendFromISR().  It is included

./Source/include/queue.h: * @param pxHigherPriorityTaskWoken xQueueGenericSendFromISR() will set

./Source/include/queue.h: * running task.  If xQueueGenericSendFromISR() sets this value to pdTRUE then

Looking at the queue.h file there is a commented  explaination about how xQueueGenericSendFromISR() work. maybe that can help. I'm adding the queue.h file to this post.

Thanks

William

queue.h

QuoteReplyEditDelete

2011-10-14 02:21:15     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 103857   

Hi William,

you shold not load test_ad1836_driver with gdb,  icc_loader -f -e test_ad1836_driver will load it, if you use gdb load test_ad1836_driver, after load it will start from basiccrt.S crt0.. and will not from your icc_task_init() entry, so you got the execption in stdlib. can you try set a breakpoint in xQueueGenericSendFromISR(), if gdb break at this breakpoint, you can run backtrace to find the call stack, and you should build it with symbol table.

-steven

QuoteReplyEditDelete

2011-10-14 05:16:58     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103865   

Hi Steven,

I tried but I get :

target remote :2000

Remote debugging using :2000

[New Thread 1]

[New Thread 2]

0xffa00358 in ?? ()

(gdb) b xQueueGenericSendFromISR

No symbol table is loaded.  Use the "file" command.

I've built the test_ad1836_driver with the option -g :

for testing when I try to put a break point on the loaded test_ad1836_driverlike this:

bfin-elf-gdb Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/test_ad1836_driver

(gdb) b xQueueGenericSendFromISR

Breakpoint 1 at 0x3c00458: file /home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/Source/include/../queue.c, line 793.

it works.

But when I load it from

icc_loader -f -e test_ad1836_driver it doesn't have the symbole table.

Do I have to make the linux kernel in debug mode: If it is the case do I use this setup or I need to do something more?

  Kernel hacking --->

    [*] Kernel debugging

    [*] KGDB: kernel debugging with remote gdb  --->

      --- KGDB: kernel debugging with remote gdb

      <*>   KGDB: use kgdb over the serial console

Don't forget to change the mode of Blackfin serial driver to PIO (not DMA). You have to enable the UART port, which you plan to connect the GDB client to. For example, if you want to run console on UART0 and connect GDB to UART1, enable both UART0 and UART1.

  Device Drivers  --->

    Character devices  --->

      Serial drivers  --->

        <*> Blackfin serial port support

        [*]   Console on Blackfin serial port

              UART Mode (PIO mode)  --->

        [*]   Enable UART0

        [*]   Enable UART1

Don't forget to unselect watchdog timer. Otherwise, kernel may be reset in debug mode.

  Device Drivers  --->

    Character devices  --->

      [*] Watchdog Timer Support  --->

        < >   Blackfin On-Chip Watchdog Timer

the -g option is already in the compilation of icc_core and icc_loader

QuoteReplyEditDelete

2011-10-14 07:59:21     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103867   

Hi Steven,

I've try to recompile the kernel with the kgdb option above but it did change nothing for my gdb session, it still say:

(gdb) b xQueueGenericSendFromISR

No symbol table is loaded.  Use the "file" command.

(gdb) b 0x3c0045c

No symbol table is loaded.  Use the "file" command.

(gdb) b -f 0x3c0045c

No symbol table is loaded.  Use the "file" command.

(gdb) b 0x3c0045c

No symbol table is loaded.  Use the "file" command.

(gdb) c

Continuing.

^[[A^C

Program received signal SIGINT, Interrupt.

0xfeb00386 in ?? ()

What do I do wrong, how do I load the symbol table to be able to add break points?

if I use the file command it is not icc_loader that load my standalone app test_ad1836_driver

Thanks

William

QuoteReplyEditDelete

2011-10-17 03:10:56     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 103891   

Hi William,

you don't have build with KGDB, you already can debug with jtag. the symbol table must be stripped when install to the romfs,

you can reference Makefile in icc-utils, task in exemple will not be stripped when install "by pass a -S option with $(ROMFSINST)".

and you can run "file test_ad1836_driver" to check if it is stripped, or "bfin-elf-readelf -S test_ad1836_driver" to check if the symstab section and debug section.

-steven

QuoteReplyEditDelete

2011-10-17 04:38:49     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103900   

Hi Steven,

doing on the pc:

file test_ad1836_driver

test_ad1836_driver: ELF 32-bit LSB executable, Analog Devices Blackfin, version 1 (SYSV), statically linked, not stripped

bfin-elf-readelf -S test_ad1836_driver

There are 19 section headers, starting at offset 0x11ebc:

Section Headers:

  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al

  [ 0]                   NULL            00000000 000000 000000 00      0   0  0

  [ 1] .text             PROGBITS        03c00000 001000 003660 00  AX  0   0  4

  [ 2] .data_icc         PROGBITS        03c03660 004660 000004 00  WA  0   0  4

  [ 3] .rodata           PROGBITS        03c03664 004664 000270 00   A  0   0  4

  [ 4] .data             PROGBITS        03c038d4 0048d4 000070 00  WA  0   0  4

  [ 5] .bss              NOBITS          03c03944 004944 005268 00  WA  0   0  4

  [ 6] .comment          PROGBITS        00000000 004944 000122 00      0   0  1

  [ 7] .debug_aranges    PROGBITS        00000000 004a68 0001a0 00      0   0  8

  [ 8] .debug_pubnames   PROGBITS        00000000 004c08 0008f2 00      0   0  1

  [ 9] .debug_info       PROGBITS        00000000 0054fa 003d1b 00      0   0  1

  [10] .debug_abbrev     PROGBITS        00000000 009215 001037 00      0   0  1

  [11] .debug_line       PROGBITS        00000000 00a24c 00259f 00      0   0  1

  [12] .debug_frame      PROGBITS        00000000 00c7ec 000aa8 00      0   0  4

  [13] .debug_str        PROGBITS        00000000 00d294 001a45 01  MS  0   0  1

  [14] .debug_loc        PROGBITS        00000000 00ecd9 002b43 00      0   0  1

  [15] .debug_ranges     PROGBITS        00000000 01181c 0005e0 00      0   0  1

  [16] .shstrtab         STRTAB          00000000 011dfc 0000bd 00      0   0  1

  [17] .symtab           SYMTAB          00000000 0121b4 001440 10     18  74  4

  [18] .strtab           STRTAB          00000000 0135f4 001a49 00      0   0  1

Key to Flags:

  W (write), A (alloc), X (execute), M (merge), S (strings)

  I (info), L (link order), G (group), x (unknown)

  O (extra OS processing required) o (OS specific), p (processor specific)

those look ok, so what do I do wrong, I must do something different than you?

1- I start the board

2 - on the bootloader I tftp my linux version  on u-boot format (once) to address 0x1000000

tftp 0x1000000 uImage

3 - I save permanantly my linux kernel to address

protect off 1:0-134

erase 0x20080000 0x207FFFFF cp.b 0x1000000 0x20080000 0x570000  set bootcmd bootm 0x20080000 save protect on 1:0-134   4- check that my image is valid:

iminfo 0x20080000  5- reboot and wait that uclinux has load then initialise ethernet: dhcpcd &  6- upload all the icc files via tftp:                            tftp -g -r icc 10.1.1.100 tftp -g -r icc_loader 10.1.1.100

tftp -g -r test_ad1836_driver 10.1.1.100

7 - then I make executable icc_loader:

chmod 777 icc_loader

8- then I load the icc kernel in core B :

./icc_loader -l icc

9 - on the pc I start the gdb proxy as root:

sudo bfin-gdbproxy bfin

10- on another bash terminal I start gdb as root:

sudo bfin-elf-gdb

11- in gdb I connect to the target:

target remote :2000  12- try to put a break point (even if test not loaded yet)

(gdb) b xQueueGenericSendFromISR

No symbol table is loaded.  Use the "file" command.

(gdb) b 0x3c0045c  No symbol table is loaded.  Use the "file" command.

  13 - then I type c to let the uclinux kernel to continue to run  c  14 - on the bfin UART prompt (minicom) I load the test_ad1836_driver

app:

./icc_loader -f -e test_ad1836_driver

15 - the axception keep continusly occuring, I go on gdb and try to put a break poit again withtest_ad1836_driver

loaded by  icc_loader

(gdb) b xQueueGenericSendFromISR

No symbol table is loaded.  Use the "file" command.

(gdb) b 0x3c0045c  No symbol table is loaded.  Use the "file" command.

still cannot put the break point. This is the whole procedure I do, and the Make file I use has the same option than the task Makefile.

Hope this will help you to point what I do wrong

Thanks

William

QuoteReplyEditDelete

2011-10-17 09:44:22     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103902   

As well, I noticed I did use the O3 option in my compilation, is that would have affect the debugs symbole table?

Another thing where I could have a problem is that I did struggle a bit to compile everything together, thus in my make file I had to separate the compilator and linker part:

freertos: $(FREERTOSPORTABLE_INCLUDE)/bfin_isr.s $(FREERTOSPORTABLE_INCLUDE)/po\

rtmacro.h $(FREERTOSPORTABLE_INCLUDE)/port.c $(ICC_CORE)

        $(CC) $(CFLAGS)  test_ad1836_driver.c   $(FREERTOSPORTABLE_INCLUDE)/por\

t.c $(FREERTOS_INCLUDE)/../tasks.c $(FREERTOS_INCLUDE)/../queue.c $(FREERTOS_IN\

CLUDE)/../croutine.c $(FREERTOS_INCLUDE)/../portable/MemMang/heap_2.c  $(FREERT\

OS_INCLUDE)/../list.c $(FREERTOS_BF561_INCLUDE)/app_c.c $(FREERTOS_BF561_INCLUD\

E)/ezkit_561.c  $(ASMFLAGS) $(FREERTOSPORTABLE_INCLUDE)/context_sl_asm.asm $(FR\

EERTOSPORTABLE_INCLUDE)/bfin_isr.s $(FREERTOS_BF561_INCLUDE)/user_isr.asm

test_ad1836_driver:$(FREERTOSPORTABLE_INCLUDE)/bfin_isr.s

        $(LD) -v  -o test_ad1836_driver -T  coreb_test_ad1836_driver.lds  --jus\

t-symbol $(ICC_CORE) queue.o ezkit_561.o  heap_2.o  port.o tasks.o test_ad1836_\

driver.o list.o croutine.o user_isr.o bfin_isr.o app_c.o context_sl_asm.o -Ttex\

t $(TASK_LOAD_BASE) $(LDFLAGS) -L /opt/uClinux/bfin-elf/bfin-elf/lib -lc

Notice that ICC_CORE is included only in the linker, thus I have a lot of warning about the undefined ICC_CORE function from protocol.c in the compilation part before the linker (I suposed) link them together. Is this could be a problem, if yes, how do I get all the sm_ function from protocol.c in the compiler ligne without having to recompile protocole.c?

As well to resolve conflict in my linker I had to use -lc option, is that corect?

Here is my current warning left form the compiler:

test_ad1836_driver.c:68: warning: initialisation makes pointer from integer without a cast

test_ad1836_driver.c:71: warning: initialisation makes pointer from integer without a cast

test_ad1836_driver.c:74: warning: initialisation makes pointer from integer without a cast

test_ad1836_driver.c:77: warning: initialisation makes pointer from integer without a cast

test_ad1836_driver.c:80: warning: initialisation makes pointer from integer without a cast

test_ad1836_driver.c:83: warning: initialisation makes pointer from integer without a cast

test_ad1836_driver.c: In function ‘prvSetupTimerInterrupt’:

test_ad1836_driver.c:144: warning: assignment makes pointer from integer without a cast

test_ad1836_driver.c: In function ‘icc_task_init’:

test_ad1836_driver.c:194: warning: initialisation from incompatible pointer type

test_ad1836_driver.c:247: warning: implicit declaration of function ‘sm_create_session’

test_ad1836_driver.c:388: warning: implicit declaration of function ‘icc_wait’

test_ad1836_driver.c:389: warning: implicit declaration of function ‘sm_recv_packet’

test_ad1836_driver.c:399: warning: implicit declaration of function ‘sm_send_request’

test_ad1836_driver.c:399: warning: initialisation makes pointer from integer without a cast

test_ad1836_driver.c:406: warning: implicit declaration of function ‘m_send_packet’

test_ad1836_driver.c:411: warning: implicit declaration of function ‘sm_recv_release’

test_ad1836_driver.c: In function ‘icc_task_exit’:

test_ad1836_driver.c:575: warning: implicit declaration of function ‘sm_destroy_session’

note that warning: initialisation makes pointer from integer without a cast are raw pointer I created to handle undeclare MMR register I needed to access and gives no problem at runtime when I was testing just the ad1835 driver integration.

However : implicit declaration of function... could be an issue unless the linker do resolve this when I gives to the linker:

--just-symbol $(ICC_CORE)

I thought I should mention that in case those info would help resolve this problem. (attached my Makefile)

Thanks Steven

William

Makefile

QuoteReplyEditDelete

2011-10-17 15:34:51     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103905   

Ok I went a bit further and get rid off most of the warnings,

I have a different error address now:

.................

fin set SICB MASK1: c00a8000                                          

COREB: bfin set SICB MASK1: c00a8000                                          

COREB: bfin set IAR5: 43333333                                                

COREB: bfin set IAR5: 53333333                                                

COREB: bfin set evt12: 3c030f0                                                

COREB: bfin imask core: 2df                                                   

COREB: bfin imask core: 12df                                                  

COREB: end setup LED                                                          

COREB: handler declared                                                       

COREB: task created                                                           

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8      

.....................

if I do:

bfin-uclinux-addr2line -f -e test_ad1836_driver ff700be8

??

??:0

Looking add the memory, it is in the L1 ScratchPad SRAM block.

trying using gdb this time loading icc_loader.gdb (is that what I was supose to do)?

bfin-elf-gdb icc_loader.gdb

GNU gdb 6.6

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=bfin-elf"...

(gdb) target remote:2000

Remote debugging using :2000

[New Thread 1]

[New Thread 2]

0xffa00144 in ?? ()

(gdb) b 0xff700be8

Function "0xff700be8" not defined.

Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (0xff700be8) pending.

(gdb) c

Continuing.

^C

Program received signal SIGINT, Interrupt.

[Switching to Thread 2]

0xfeb00396 in ?? ()

(gdb) bt

#0  0xfeb00396 in ?? ()

#1  0xfeb003c8 in ?? ()

trying without the functions FreeRTOS:

Works!!!

COREB: bfin set EDGE: 0                                                       

COREB: bfin set EDGE: 64                                                      

COREB: bfin set MASKA: 200                                                    

COREB: bfin set MASKA: 240                                                    

COREB: bfin read MASKA Clear: 240                                             

COREB: bfin read MASKA Clear: 240                                             

COREB: bfin read MASKA data: 240                                              

COREB: bfin set SICB MASK1: c00a8000                                          

COREB: bfin set SICB MASK1: c00a8000                                          

COREB: bfin set IAR5: 43333333                                                

COREB: bfin set IAR5: 53333333                                                

COREB: bfin set evt12: 3c0306c                                                

COREB: bfin imask core: 2df                                                   

COREB: bfin imask core: 12df                                                  

COREB: end setup LED                                                          

COREB: in while looproot:/>                                                   

root:/>                                                                       

root:/>

It Works!!!

So it is definitly a conflict of FreeRTOS with icc....

Do you think it is a sharing  memory problem. How icc manage interuption coompare to Free RTOS?

where will be the best place for me to debug from here.

hanks again for all your help

Best Regards,

William

T

QuoteReplyEditDelete

2011-10-18 07:18:51     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 103957   

Hi William,

I have no idea why your test_ad1836_driver has no symbol table and can not debug. can you compress the whole test_ad1836_driver build dir with freertos(queue.c task.c ...), I can try to build and load it.

-steven

QuoteReplyEditDelete

2011-10-18 07:42:52     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103959   

Hi Steven,

Great, thanks for that, It would be really handy if I could debug with gdb.

Attached is the whole FreeRTOS implementation with icc and AD1836.

Sorry it is a bit messy as I tried to get this simple integration example of the main code blocks running before to make a real organised framework around the full integration.

Any tip though welcome.

Best Regards,

William

Free_RTOS_imp.tar.bz2

QuoteReplyEditDelete

2011-10-18 23:19:36     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 103965   

Hi William,

I have tested with your free RTOS, debug with jtag and gdb is OK. So what is the blackfin toolchain version?

GNU gdb 6.6

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "--host=i686-pc-linux-gnu --target=bfin-uclinux"...

[New Thread 1]

[New Thread 2]

0xffa00144 in ?? ()

(gdb) thread 2

[Switching to thread 2 (Thread 2)]#0  0xfeb04be0 in ?? ()

(gdb) hb icc_task_init

Function Prologue not recognised. pc will point to ENTRY_POINT of the function

Hardware assisted breakpoint 1 at 0x3c0289e: file test_ad1836_driver.c, line 208.

(gdb) c

Continuing.

[Switching to Thread 2]

Breakpoint 1, icc_task_init (argc=2, argv=0xff700f78) at test_ad1836_driver.c:208

208        int len = 0;

(gdb) l

203  

204    void  icc_task_init(int argc, char *argv[])

205    {

206    //    struct sm_session *session;

207        void *buf;

208        int len = 0;

209        int ret;

210        sm_uint16_t src_ep, src_cpu,dst_cpu;

211          

212    //        int dst_cpu;

(gdb) info breakpoints

Num Type           Disp Enb Address    What

1   hw breakpoint  keep y   0x03c0289e in icc_task_init at test_ad1836_driver.c:208

    breakpoint already hit 1 time

QuoteReplyEditDelete

2011-10-18 23:34:36     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 103967   

Hi William,

Maybe you missed something in GDB debug. The step is:

1 # bfin-gdbproxy bfin                               (run gdbproxy then gdb can attach the jtag, should run as root in another console)

2 bfin-uclinux-gdb test_ad1836_driver (load debug program name)

3 in gdb console run,   target remote :2000

4 then you can debug with gdb

for details you can follow:

https://docs.blackfin.uclinux.org/doku.php?id=toolchain:debug:gdbproxy

-steven

QuoteReplyEditDelete

2011-10-19 01:19:22     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103971   

Hi Steven,

I'm using the same version as you for GDB

I think in most of the test I did bfin-uclinux-gdb

instead bfin-uclinux-gdb  test_ad1836_driver As you told me to not load test_ad1836_driver directly it confused me, so I wasn't do that anymore.

Now the debug works.

I will put back FreeRTOS part and backtrace it and will get back to you in case of struggle or success

Thanks again

Best Regards,

William

QuoteReplyEditDelete

2011-10-19 08:58:49     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103990   

Hi Steven,

putting back the FreeRTOS functions, I've got an exeption error again when the vTaskStartScheduler(); function is called

this is the  terminal coreb print I've got:

......................

COREB: bfin set SICB MASK1: c00a8000                                          

COREB: bfin set IAR5: 43333333                                                

COREB: bfin set IAR5: 53333333                                                

COREB: bfin set evt12: 3c030f0                                                

COREB: bfin imask core: 2df                                                   

COREB: bfin imask core: 12df                                                  

COREB: end setup LED                                                          

COREB: handler declared                                                       

COREB: task created                                                           

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8  

.............

this is the gdb monitor I tried:

target remote:2000

Remote debugging using :2000

[New Thread 1]

[New Thread 2]

0xffa00144 in ?? ()

(gdb) hb xQueueGenericSendFromISR

Hardware assisted breakpoint 1 at 0x3c0029e: file /home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/Source/include/../queue.c, line 806.

(gdb) c

Continuing.

^C

Program received signal SIGINT, Interrupt.

[Switching to Thread 2]

0xfeb00390 in ?? ()

(gdb) hb ff700be8

Function "ff700be8" not defined.

Make breakpoint pending on future shared library load? (y or [n]) ^Cn

(gdb) Quit

(gdb) hb 0xff700be8

the exeption have 2b addr in addition what does that mean?

ff700be8  is in the scratch pad of L1 memory block not sure what use it

vTaskStartScheduler() create an idle task at the lowest priority

In previous post where you demo the gdb use you type thread2 (is that to switch to core b) what advantage this command gives?

As well I'm trying to to put a breakpoint within vTaskStartScheduler() function, hiow do I do that. In previous example I see that you use the command (gdb) l

this command doesn't work for me.

I let you know if I go further.

Best Regards,

William

QuoteReplyEditDelete

2011-10-19 09:01:24     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103991   

As well could you tell me a way to just reload the test_ad1836_driver with icc_loader instead to have to reboot each time uclinux kernel and tftp back icc, icc_loader and test_ad1836_driver then have to reload the icc core and test_ad1836_driver app?

QuoteReplyEditDelete

2011-10-19 10:18:51     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 103994   

Hi Steven,

ok I went a bit further in the debugging:

I tracked with GDB where the error:

COREB: execption 2b addr ff700be8 happen

this is the flow:

vTaskStartScheduler(); (task.c) is called then it run the function until:

xPortStartScheduler() (port.c) which seem normal as it says in comment:

       /* Should not reach here as if the scheduler is running\

the                                                                          

                        function will not return. */

in xPortStartScheduler() it run until the function vStartFirstTask();

which again seem normal as the comment after this function  says:

    /* Should never get here! */

this triger the task initialisation   app_init in (ezkit_561.c)

Which look like this:

void app_init(void)

{

        EZKit_Init_Flags();

        EZKit_Init_Interrupts();

        // Create 2 semaphores for 2 LEDs that will toggled through push button\

s                                                                             

        vSemaphoreCreateBinary( LED0_semaphore );

        vSemaphoreCreateBinary( LED5_semaphore );

        params[0].event = LED0_semaphore;

        params[5].event = LED5_semaphore;

}// end of app_init

once it reach the end of the function and get out of it gdb stall and the output of the RS232 terminal keep seending:

-----

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8       

------

So it is when it exist from this function that the exception happen.

(gdb)

app_init ()

    at /home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/BF561/app_c.c:62

62        params[0].event = LED0_semaphore;

(gdb)

63        params[5].event = LED5_semaphore;

(gdb)

64    }// end of app_init

(gdb)

c

^C

Program received signal SIGINT, Interrupt.

0xfeb00388 in ?? ()

(gdb) bt

#0  0xfeb00388 in ?? ()

#1  0xfeb003c8 in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb)

is that mean that the stack pointer went lost in memory after that function? How that can have happen?

How I debug further from there?

BTW: I figure out that l was no | the bare but l "L" the letter which mean list in gdb to look at the code.

Best Regatds,

QuoteReplyEditDelete

2011-10-24 00:31:47     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104121   

Hi Steven,

Didn't heard from you. could you tell me what :

COREB: execption 2b addr ff700be8  

mean? why is it stuck in the scratchpad sram?

I tried to have a look at the error code 2b but cannot find anything.

Thanks,

William

QuoteReplyEditDelete

2011-10-24 01:14:06     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104123   

Hi William,

ff700be8 is in scratchpad of coreb, scratchpad has 4K size, and we use scratchpad as stack of coreb task. The stack could be broken by free RTOS task init code. How do you implement the task init code for bf561, will the free RTOS switch the task stack?

-steven

QuoteReplyEditDelete

2011-10-24 02:45:36     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104124   

Hi Steven,

Following what you said, I've looked in the FreeRTOS code where the stack could have been initialised for the task.

in Source/task.c I found:

static tskTCB *prvAllocateTCBAndStack( unsigned short usStackDepth, portSTACK_T\

YPE *puxStackBuffer )

{

tskTCB *pxNewTCB;

    /* Allocate space for the TCB.  Where the memory comes from depends on

        the implementation of the port malloc function. */

    pxNewTCB = ( tskTCB * ) pvPortMalloc( sizeof( tskTCB ) );

        if( pxNewTCB != NULL )

           {

              /* Allocate space for the stack used by the task being created.

                The base of the stack memory stored in the TCB so the task can

                be deleted later if required. */

                pxNewTCB->pxStack = ( portSTACK_TYPE * ) pvPortMallocAligned( (\

( ( size_t )usStackDepth ) * sizeof( portSTACK_TYPE ) ), puxStackBuffer );

........................

Which is called by: xTaskGenericCreate function

looking at the portMalloc function implemented in Source/portable/MemMang/heap_2.c:

this is the heap union structur:

/* Allocate the memory for the heap.  The struct is used to force byte        

alignment without using any non-portable code. */

static union xRTOS_HEAP

{

        #if portBYTE_ALIGNMENT == 8

                volatile portDOUBLE dDummy;

        #else

                volatile unsigned long ulDummy;

        #endif

        unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];

} xHeap;

this is the heap init function:

prvHeapInit()                                       

{                                

xBlockLink *pxFirstFreeBlock;                                 

        /* xStart is used to hold a pointer to the first item in the list of free */

        /* blocks.  The void cast is used to prevent compiler warnings. */

        xStart.pxNextFreeBlock = ( void * ) xHeap.ucHeap;          

                                         \

        xStart.xBlockSize = ( size_t ) 0;       

        /* xEnd is used to mark the end of the list of free blocks. */    

     xEnd.xBlockSize = configTOTAL_HEAP_SIZE;                        

        xEnd.pxNextFreeBlock = NULL;     

   /* To start with there is a single free block that is sized to take up \

the entire heap space. */                                 

        pxFirstFreeBlock = ( void * ) xHeap.ucHeap;           

                                                 \

        pxFirstFreeBlock->xBlockSize = configTOTAL_HEAP_SIZE;         

                                 \

        pxFirstFreeBlock->pxNextFreeBlock = &xEnd;       

}

pvPortMalloc does call prvHeapInit() if not initialised.

Looking at gdb:

Breakpoint 1, prvAllocateTCBAndStack (usStackDepth=400, puxStackBuffer=0x0)

    at /home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/Source/include/../tasks.c:2190

2190        pxNewTCB = ( tskTCB * ) pvPortMalloc( sizeof( tskTCB ) );

p usStackDepth

$1 = 400

(gdb) p puxStackBuffer

$2 = (long unsigned int *) 0x0

x/b & xStart.pxNextFreeBlock

0x3c092c4 <xStart>:    0x00

(gdb) x/b & xStart.xBlockSize

0x3c092c8 <xStart+4>:    0x00

step

Sport0_RX_ISR () at Initialize.c:23

23            bfin_write_DMA2_0_IRQ_STATUS(0x0001);

(gdb) b prvHeapInit

Function "prvHeapInit" not defined.

Make breakpoint pending on future shared library load? (y or [n]) y

x/b & pxNewTCB->pxStack

0x40:    0xcc

(gdb) delete

Delete all breakpoints? (y or n) y

(gdb) b pxPortInitialiseStack

Breakpoint 4 at 0x3c00f06: file /home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/Source/portable/ADI_VDSP/Blackfin/port.c, line 87.

(gdb) c

Continuing.

Breakpoint 4, pxPortInitialiseStack (pxTopOfStack=0x3c04954,

    pxCode=0x3c02868 <vBootTask>, pvParameters=0x0)

    at /home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/Source/portable/ADI_VDSP/Blackfin/port.c:87

87        ulAddress = ( unsigned portLONG ) pxCode;

(gdb) x/b & ulAddress

0xff700cd4:    0x18

(gdb) b xTimerCreateTimerTask

Function "xTimerCreateTimerTask" not defined.

Make breakpoint pending on future shared library load? (y or [n]) n

(gdb) b xTimerCreateTimerTask()

Function "xTimerCreateTimerTask()" not defined.

Make breakpoint pending on future shared library load? (y or [n]) n^[[A

(gdb) b xTimerCreateTimerTask

Function "xTimerCreateTimerTask" not defined.

Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 6 (xTimerCreateTimerTask) pending.

this is from  xTaskGenericCreate function:

/* Initialize the TCB stack to look as if the task was already \

running,                                                                      

                but had been interrupted by the scheduler.  The return address \

is set                                                                        

                to the start of the task function. Once the stack has been init\

ialised                                                                       

                the     top of stack variable is updated. */

                #if( portUSING_MPU_WRAPPERS == 1 )

                {

                        pxNewTCB->pxTopOfStack = pxPortInitialiseStack( pxTopOf\

Stack, pxTaskCode, pvParameters, xRunPrivileged );

                }

                #else

                {

                        pxNewTCB->pxTopOfStack = pxPortInitialiseStack( pxTopOf\

Stack, pxTaskCode, pvParameters );

                }

Is that answere how free rtos initialise the task? Tell me if I got it wrong.

How can I debug that? I tried with gdb as you  can see to look at heap variable etc .... but I'm not to sure what I'm looking for. How can we get the icc heap and the freeRTOS heap compatible?

Thanks

William

QuoteReplyEditDelete

2011-10-24 03:23:10     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104126   

Hi William,

It seems there is a lot of work to do to port a free RTOS to bf561, do you have any guide about free RTOS porting? For your posted code, you should init the heap first to make sure pvPortMalloc() can work, icc should use the last 4M memory, so you get the pxNewTCB address is wrong and will conflict with linux memory space. you can put the xHeap struct to last 1M memory as free RTOS heap, but I am not a expert of free RTOS, you'd better follow a porting guide of free RTOS to find out how many stub or init code you should implement.

-steven

QuoteReplyEditDelete

2011-10-24 03:51:56     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104129   

HI Steven,

In fact the Free RTOS version I'm using is for bf561, the only thing is that it was made for VDSP compiler so that is where I did most of the change to convert the code form VDSP to gcc-elf and from coreA to coreB.

I've read all the doc from FreeRTOS but cannot find enought info about the porting part. Nevertheless all this work has been done for me I just have to make it work on coreB and compiled on gcc.

I think I'm really close, I just need to understand and resolve this heap memory conflict and I may be good.

" init the heap first to make sure pvPortMalloc() can work" How do I do that, you mean before loading icc_core? Should I implement that in icc?

"you can put the xHeap struct to last 1M memory as free RTOS heap"

curently, freeRTOS heap is 20k:

#define configTOTAL_HEAP_SIZE           ( ( size_t ) ( 20 * 1024 ) )

"icc should use the last 4M memory"

Where do I change this parameter?

"so you get the pxNewTCB address is wrong and will conflict with linux memory space" What have make you notice that, is resolving theap problem could solve that :(make sure pvPortMalloc() can work)

Is there is a good tool I can use to debug the heap memory?

Thanks,

WIlliam

QuoteReplyEditDelete

2011-10-24 05:05:40     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104131   

Hi William,

ok, let's resolve this heap issue first.

(gdb) p puxStackBuffer

$2 = (long unsigned int *) 0x0

   x/b & xStart.pxNextFreeBlock

0x3c092c4 <xStart>:    0x00

here get the address 0x0, and pxNextFreeBlock is 0x0, it should not be init correctly.

in linux-kernel/arch/blackfin/mach-bf561/include/mach/icc.h

#define COREB_MEMPOOL_START 0x3D00000                          (61M of total 64M ram, a bit hard code)

in icc_core/corebboot.c icc_init(), we init 2 mempool for fixed 4K buffer and message

so last 2M ram is free, you can put the heap here 0x3E00000

after init head properly, you will get the address of pvPortMalloc() above 0x3E00000

-steven

QuoteReplyEditDelete

2011-10-24 09:16:37     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104134   

Hi steven,

I will have to test tomorow on the board. But from your instruction, this is what I did to move the FreeRTOS heap around:

in BF561.lds I've split the MEM_ICC to ge the 2 last meg for freeRTOS heap:

MEMORY

{

  MEM_L1_CODE : ORIGIN = 0xFF600000, LENGTH = 0x4000

  MEM_L1_CODE_CACHE : ORIGIN = 0xFF610000, LENGTH = 0x4000

  MEM_L1_SCRATCH : ORIGIN = 0xFF700000, LENGTH = 0x1000

  MEM_L1_DATA_B : ORIGIN = 0xFF500000, LENGTH = 0x8000

  MEM_L1_DATA_A : ORIGIN = 0xFF400000, LENGTH = 0x8000

  MEM_L2 : ORIGIN = 0xFEB00000, LENGTH = 0x20000

  MEM_ICC : ORIGIN = 0x3C00000, LENGTH = 0x200000

  MEM_FREERTOS : ORIGIN = 0x3E00000, LENGTH = 0x200000

}

Then in coreb_test_ad1836_driver.lds

I've added at the end the address for the union structure (xheap) that hold the heap array (ucheap):

  /*set FreeRTOS  heap memory origin */

  _xHeap = ORIGIN(MEM_FREERTOS);

It compile without any problem, I will test it tomorow on the board to see if it solve the problem and will tell you the outcom. Let me know if I'm totally wrong in my ay to set the heap memory address

Thanks,

William

QuoteReplyEditDelete

2011-10-24 22:04:32     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104137   

Hi William,

You can qucikly check the if the link result by bfin-uclinux-objdump to find out the xHeap address and in which section it locate.

-steven

QuoteReplyEditDelete

2011-10-24 23:27:14     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104140   

Hi Steven

using bfin-uclinux-objdump:

....

03e00000 g       *ABS*    00000000 _xHeap

.....

on the debugging part with  gdb:

(gdb) b vTaskStartScheduler

Function Prologue not recognised. pc will point to ENTRY_POINT of the function

Breakpoint 1 at 0x3c01828: file /home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/Source/include/../tasks.c, line 1096.

(gdb) c

Continuing.

it got

the exact same error:

COREB: execption 2b addr ff700be8 

when the RS232 terminal show:

COREB: bfin set evt12: 3c03110                                                

COREB: bfin imask core: 2df                                                   

COREB: bfin imask core: 12df                                                  

COREB: end setup LED                                                          

COREB: handler declared                                                       

COREB: task created                                                           

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8                                             

COREB: execption 2b addr ff700be8   

in the code that corespond to:

    xTaskHandle xHandle = NULL;

    coreb_msg("handler declared");

        //printf("FreeRTOS demo on BF561\n");                                 

        xTaskCreate( vBootTask,(signed char*) "BootTask", 400, (void *)xHandle,\

1,&xHandle);

       coreb_msg("task created");

        vTaskStartScheduler();

        coreb_msg("scheduler started");

so it triger the error just before entering the function where I did put a brake point.

I keep looking, but starting the heap array at a different address seem to not have resolve the problem

I atteched the full obj dump of the file in case you can see something in there.

Thanks,

William

test_ad1836_driver_objdum.txt

QuoteReplyEditDelete

2011-10-24 23:28:57     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104141   

Can you tell me as well how do I reload icc in coreB without having to reboot the whole uClinux system?

QuoteReplyEditDelete

2011-10-24 23:57:11     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104142   

Hi Steven,

Strange, when I try to make a brake point to xTaskCreate this one is not reconised.

When I look at the symbol list of objdump it is not there anymore.

in the code xTaskCreate is declare in Source/include/task.h:

#define xTaskCreate( pvTaskCode, pcName, usStackDepth, pvParameters, uxPriority\

, pxCreatedTask ) xTaskGenericCreate( ( pvTaskCode ), ( pcName ), ( usStackDept\

h ), ( pvParameters ), ( uxPriority ), ( pxCreatedTask ), ( NULL ), ( NULL ) )

I did a search in the folder for its implementation but I find nothing and the compiler give no warning about that I don't really understand why, it is declare in the MACRO way but with the implementation.

QuoteReplyEditDelete

2011-10-25 00:30:38     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104143   

Hi Steven,

It goes in xTaskGenericCreate when calling xTaskCreate, didn't find the link but at least it is happy about that.

debugging a bit more is xTaskGenericCreate I've got this:

473                pxTopOfStack = ( portSTACK_TYPE * ) ( ( ( unsigned long ) pxTopOfStack ) & ( ( unsigned long ) ~portBYTE_ALIGNMENT_MASK  ) );

474  

475                /* Check the alignment of the calculated top of stack is correct. */

476                configASSERT( ( ( ( unsigned long ) pxTopOfStack & ( unsigned long ) portBYTE_ALIGNMENT_MASK ) == 0UL ) );

(gdb) x/b & pxNewTCB

0xff700cfc:    0xd0

(gdb) x/b & pxNewTCB->pxStack

0x3c04300 <xHeap+60>:    0x18

when it says xHeap+60 I would have though it would be 0x3e00000 + 60 not 0x3c04300

also,

(gdb)x/b & pxTCB

0xff700ce4:    0xd0

which is close to the error address: COREB: execption 2b addr ff700be8

I cannot step it really, my add1836 interupt alway trigger and I go back to the break point.

I might try a code version without the ad1836 interupt on to simplify debugging

Thanks,

William

QuoteReplyEditDelete

2011-10-25 00:48:36     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104144   

Hi William,

It seems _xHeap is in bss section

03c042c4 l     O .bss    00005000 _xHeap

03c092c4 l     O .bss    00000008 _xStart

03c092cc l     O .bss    00000008 _xEnd

you can add a new data section(data_heap) like data_icc section in coreb.lds instead of auto link it by bfin-elf-ld to bss section.

use __attribute__ ((__section__("data_heap"))) when declare xHeap union structure.

-steven

QuoteReplyEditDelete

2011-10-25 02:30:43     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104145   

Hi Steven,

ok so I added in heap_2.c:

.....

__attribute__ ((__section__(".data_heap"))) static union xRTOS_HEAP

{

.....

then in coreb_test_ad1836_driver.lds:

.data_icc        :

  {

    *(.icc.data)

  } >MEM_ICC =0

  .data_heap      :

  {

    *(.data_heap)

  } >MEM_FREERTOS =0

What do I have to put in this new section? all the FreeRTOS code or just it's heap?

checking in gdb:

(gdb) x/b & xHeap

0x3e00000 <xHeap>:    0x00

now I have a different exception address howver:

execption 2c addr 4000000

Is that mean we have fix this problem and ther is another problem now? How do I trace what happened at address 4000000?

Looking at the memory blocks, this address is right at the start of coreb L1 DATA BANK A SRAM section.

QuoteReplyEditDelete

2011-10-25 02:38:41     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104146   

Hi Steven,

Actually, this time it made the exception before any freeRTOS code is initialised I think. It crash when doing icc stuff. maybe it is my icc packet which is wrong:

./icc_loader -f -e test_ad1836_driver                                 

writing to 0x03c00000, 0x4528    bytes: OK                                    

writism_debug:sm_find_session bits 00000000 localep 0                         

sm_debug:table bits1 00000000                                                 

sm_debug:table index 0                                                        

sm_debug:table bits2 00000001                                                 

sm_debug:create ep index 0 srcep 0 type 2                                     

sm_debug:session 028f3828                                                     

sm_debug:sm_send_packet: 0 028f3828                                           

sm_debug:alloc buffer 2941400                                                 

sm_debug:sm_task_sendmsg msg type 2000000                                     

sm_debug:sm_task_sendmsg init addr03c028b4                                    

sm_debug:sm_send_packet: len 332 type 2000000 dst 1 dstep 5 src 0 srcep 0     

sm_debug:sm_send_message_internal: dst 1 src 0 02000000                       

sm_debug:send message cpu 1 sent 1                                            

COREB: sm_handle_control_message type 2000000                                 

ng to 0x03e00000, 0x5000    bytes: OK                                         

task_init_addr 3c028b4                                                        

COREB: sm_handle_control_message 2000000 2000000                              

COREB: task init 3c028b4 exit 3c030f0                                         

COREB: sm_send_message_internal() dst 0 src 1 2000001                         

sm_debug:sm_find_session bits 00000001 localep 0                              

sm_debug:index 0 ,local ep 0 type 2                                           

sm_debug:session 028f3828 index 0 msg type2000001                             

sm_debug:sm_task_recvmsg msg type 2000001                                     

sm_debug:sm_task_recvmsg free 2941400                                         

COREB: finish sm_handle_control_message task status 1                         

COREB: finish1 sm_handle_control_message task status 1                        

COREB: before run task 3c028b4                                                

COREB: execption 2c addr 4000000                                              

COREB: execption 2c addr 4000000                                              

COREB: execption 2c addr 4000000   

................

QuoteReplyEditDelete

2011-10-25 02:47:22     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104147   

Hi William,

4000000 is the end of 64M ram, i guess there is a heap over flow problem.

-steven

QuoteReplyEditDelete

2011-10-25 02:59:28     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104148   

Hi Steven,

it seem like it. I did further test with gdb to track from icc_run_task function and it seem to loose the stack:

(gdb) b icc_run_task

Breakpoint 1 at 0xfeb04938

(gdb) c

Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.

0x000b437e in ?? ()

(gdb) bt

#0  0x000b437e in ?? ()

#1  0x000b1dda in ?? ()

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

(gdb) step

Cannot find bounds of current function

is that our previous cut of icc mem from 3c00000 to 3dfffff instead of 3c00000 to 3ffffff ?

does the heap space for freeRTOS take the space of icc code?

the code crash just before to run the application test_ad1836_driver

I attache the latest dumpobj file in case you can see a conflict in there

Thanks William

test_ad1836_driver_objdum.txt

QuoteReplyEditDelete

2011-10-25 03:21:00     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104149   

Hi William,

Program Header:

    LOAD off    0x00001000 vaddr 0x03c00000 paddr 0x03c00000 align 2**12

         filesz 0x000042c0 memsz 0x00004528 flags rwx

    LOAD off    0x00006000 vaddr 0x03e00000 paddr 0x03e00000 align 2**12

         filesz 0x00005000 memsz 0x00005000 flags rw-

icc code load at vaddr 0x03c00000, and memsz 0x00004528, then from 0x03d00000 is icc mempool, size is 4K * 64 + sizeof(struct sm_message) * 64, should not more than 1M, so put heap at 0x03e00000 should be safe.

MEM_ICC : ORIGIN = 0x3C00000, LENGTH = 0x100000

the icc mem length should be 0x100000 now?

-steven

QuoteReplyEditDelete

2011-10-25 03:53:37     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104165   

Hi Steven,

I tried:

  MEM_ICC : ORIGIN = 0x3C00000, LENGTH = 0x100000

  MEM_FREERTOS : ORIGIN = 0x3E00000, LENGTH = 0x100000

I was at 0x200000 before for the lenght of MEM_ICC

I run and still the same problem:

Program Header:

    LOAD off    0x00001000 vaddr 0x03c00000 paddr 0x03c00000 align 2**12

         filesz 0x000042c0 memsz 0x00004528 flags rwx

    LOAD off    0x00006000 vaddr 0x03e00000 paddr 0x03e00000 align 2**12

         filesz 0x00005000 memsz 0x00005000 flags rw-

I tried to load the icc_core with gdb to trace it but I get:

(gdb) b sm_connect_session

Function Prologue not recognised. pc will point to ENTRY_POINT of the function

Breakpoint 1 at 0xfeb0307e: file protocol.c, line 298.

(gdb) b icc_run_task

Function Prologue not recognised. pc will point to ENTRY_POINT of the function

Breakpoint 2 at 0xfeb04938: file /home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/icc_core/../../../../linux-2.6.x/arch/blackfin/include/asm/processor.h, line 134.

(gdb) c

Continuing.

And the program do not stop when it supose to break at those point. Not sure if I did something wrong in the debug manip. I do bfin-uclinux-gdb icc

Do I need to do that on the icc_loader side?

So I still have the same error

Thanks

William

QuoteReplyEditDelete

2011-10-25 22:41:04     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104171   

Hi Steven,

I tried to put back the heap of FreeRTOS where it was previously to chack that it was the last modification that triger the error when icc load the testad1836_driver program.

when I do so, we are back with the initial error. So we definilty upset the program by putting the heap at 3e00000

icc seam to not like it.

in FreeRTOS config I have:

#define configMINIMAL_STACK_SIZE        ( ( unsigned portSHORT ) 200 )

#define configTOTAL_HEAP_SIZE           ( ( size_t ) ( 20 * 1024 ) )

which is the size of the heap:

static union xRTOS_HEAP

{

        #if portBYTE_ALIGNMENT == 8

                volatile portDOUBLE dDummy;

        #else

                 volatile unsigned long ulDummy;

        #endif

    unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];

} xHeap;

Which should be 20 * 1024 = 20k (is that right?)

Thanks,

William

QuoteReplyEditDelete

2011-10-25 23:01:02     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104173   

Hi William,

yeah, it's 20k, do you find which code line trigger the 4000000 exception?

-steven

QuoteReplyEditDelete

2011-10-25 23:22:36     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104174   

Hi steven,

I have no Idea,

All I know is that it hapen before the app is loaded at the end of the icc_core code

COREB: finish sm_handle_control_message task status 1                         

COREB: finish1 sm_handle_control_message task status 1                        

COREB: before run task 3c028b4                                                

COREB: execption 2c addr 4000000  

When I try addr to line in all the programs I've got nothing:

bfin-uclinux-addr2line -f -e icc_loader.gdb 0x4000000

??

??:0

bfin-uclinux-addr2line -f -e icc 0x4000000

??

??:0

bfin-uclinux-addr2line -f -e test_ad1836_driver 0x4000000

??

??:0

but it is linked with the change of address we did for xHeap struc as when I reverse this change we go back to the

COREB: execption 2b addr ff700be8

Thanks,

William

QuoteReplyEditDelete

2011-10-26 00:35:58     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104175   

Hi Steven,

ok so checking for 3c028b4 instead:

bfin-uclinux-addr2line -f -e test_ad1836_driver 3c028b4

icc_task_init

/home/william/Development_new/Music_Recognition/code/uCLinux/uclinux-dist/user/blkfin-apps/icc_utils/example/Free_RTOS_imp/test_ad1836_driver.c:213

right on void  icc_task_init(int argc, char *argv[])

{

it seem to crash when it try to load this function, so that must be the line where it crash.

if I do 0x4000000 - 0x3c028b4 this gives  0x3FD74C left for the code and the heap before 0x4000000

If I remove the heap allocation mem, I've got 0x4000000 - 100000 = 0x3F00000

but the heap is declared at 0x3E00000, is that mean we have waist 1M from 3F00000 to 4000000

So theoretically, my app test_ad1836_driver is spread on : 0x3E00000 - 0x3c028b4 = 1FD74C

Converting to decimal: 0x 1FD74C = d2086732 = 2M

is that right? or it is spread on other memory place according to the lds map, when objdump I can see addresses around the feb00000 area.

when I do bfin-uclinux-objdump -f test_ad1836_driver

I've got :

EXEC_P, HAS_SYMS, D_PAGED

start address 0xfeb00018

is that a concern?

Maybe I should try to put the memory heap at 3f00000, what do you think?

Best Regards,

William

QuoteReplyEditDelete

2011-10-26 03:03:11     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104176   

Hi Steven,

I try to shift the heap array further in the memory to 3F00000 instead.

I have the same problem:

./icc_loader -f -e test_ad1836_driver                                 

writing to 0x03c00000, 0x4528    bytes: OK                                    

writsm_debug:sm_find_session bits 00000000 localep 0                          

sm_debug:table bits1 00000000                                                 

sm_debug:table index 0                                                        

sm_debug:table bits2 00000001                                                 

sm_debug:create ep index 0 srcep 0 type 2                                     

sm_debug:session 028f3828                                                     

ingsm_debug:sm_send_packet: 0 028f3828                                        

sm_debug:alloc buffer 2b10a00                                                 

sm_debug:sm_task_sendmsg msg type 2000000                                     

sm_debug:sm_task_sendmsg init addr03c028b4                                    

sm_debug:sm_send_packet: len 332 type 2000000 dst 1 dstep 5 src 0 srcep 0     

sm_debug:sm_send_message_internal: dst 1 src 0 02000000                       

sm_debug:send message cpu 1 sent 1                                            

COREB: sm_handle_control_message type 2000000                                 

to 0x03f00000, 0x5000    bytes: OK                                           

task_init_addr 3c028b4                                                        

task_exit_addr 3c030f0                                                        

COREB: sm_handle_control_message 2000000 2000000                              

COREB: task init 3c028b4 exit 3c030f0                                         

COREB: sm_send_message_internal() dst 0 src 1 2000001                         

sm_debug:sm_find_session bits 00000001 localep 0                              

sm_debug:index 0 ,local ep 0 type 2                                           

sm_debug:session 028f3828 index 0 msg type2000001                             

sm_debug:sm_task_recvmsg msg type 2000001                                     

sm_debug:sm_task_recvmsg free 2b10a00                                         

COREB: finish sm_handle_control_message task status 1                         

COREB: finish1 sm_handle_control_message task status 1                        

COREB: before run task 3c028b4                                                

COREB: execption 2c addr 4000000                                              

COREB: execption 2c addr 4000000      

notice in red that the icc task it try to lauch before the exception occure is only  83C long = 2k

maybe it doesn't like the ofset of the heap compare to the rest of the program.

What I could I try to fix it?

Thanks

William

QuoteReplyEditDelete

2011-10-26 03:33:28     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104186   

Hi William,

I think this issue probably cause by linking the free RTOS to icc task. I have no good idea to quickly fix it, you could try to comment some free RTOS code, and add free RTOS implementation step by step. Another way is to mark the memory area(mark heap area with 0xAA, icc mempool ...) to see if there is a overflow.

-steven

QuoteReplyEditDelete

2011-10-26 04:15:42     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104187   

Hi Steven,

I tried with all the code commented of freeRTOS excepted the include files so I can still allocate the heap memory to see if it change anything.

I have the exact same error even if I do not use FreeRTOS.

./icc_loader -f -e test_ad1836_driver                                 

writing to 0x03c00000, 0x4528    bytes: OK                                    

writism_debug:sm_find_session bits 00000000 localep 0                         

sm_debug:table bits1 00000000                                                 

sm_debug:table index 0                                                        

sm_debug:table bits2 00000001                                                 

sm_debug:create ep index 0 srcep 0 type 2                                     

sm_debug:session 028f3828                                                     

sm_debug:sm_send_packet: 0 028f3828                                           

sm_debug:alloc buffer 2941400                                                 

sm_debug:sm_task_sendmsg msg type 2000000                                     

sm_debug:sm_task_sendmsg init addr03c028b4                                    

sm_debug:sm_send_packet: len 332 type 2000000 dst 1 dstep 5 src 0 srcep 0     

sm_debug:sm_send_message_internal: dst 1 src 0 02000000                       

sm_debug:send message cpu 1 sent 1                                            

nCOREB: sm_handle_control_message type 2000000                                

g to 0x03e00000, 0x5000    bytes: OK                                          

task_init_addr 3c028b4                                                        

COREB: sm_handle_control_message 2000000 2000000                              

COREB: task init 3c028b4 exit 3c030f0                                         

COREB: sm_send_message_internal() dst 0 src 1 2000001                         

sm_debug:sm_find_session bits 00000001 localep 0                              

sm_debug:index 0 ,local ep 0 type 2                                           

sm_debug:session 028f3828 index 0 msg type2000001                             

sm_debug:sm_task_recvmsg msg type 2000001                                     

sm_debug:sm_task_recvmsg free 2941400                                         

COREB: finish sm_handle_control_message task status 1                         

COREB: finish1 sm_handle_control_message task status 1                        

COREB: before run task 3c028b4                                                

COREB: execption 2c addr 4000000                                              

COREB: execption 2c addr 4000000                                              

COREB: execption 2c addr 4000000              

So it doesn't seem to be a problem with RTOS but more how the heap is allocated

I really need FreeRTOS as I need to run a DSP like for coreB with good time stamping and reliable task. ICC is conveniant as it provide me a way to upload my app on core B and a protocol to communicate with core A .

Isn't it a standard way to do it? one linux kernel, one dsp kernel for the sensors with and RTOS on it?

I did sspend a lot of time to make it work it seem so close. do you have some doc on how the icc thread work? it seem the freeRTOS code is not executed in this part non of the function are called. Only icc_core function are used and it crash when it want to load the test_ad1836_driver app due to our allocation of heap. but the test_ad1836_driver didn't run yet.

Could we allocate the heap array in the scratch pad part of the memory instead?

thanks

William

QuoteReplyEditDelete

2011-10-26 06:16:17     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104188   

Hi William,

how about drop the free RTOS first, just link in the heap array, and test alloc/free from heap, since your test_ad1836_driver can load and work at first. That will not do much change to the original test_ad1836_driver, we can just watch the heap free head.

-steven

QuoteReplyEditDelete

2011-10-26 23:43:14     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104191   

Hi Steven,

This is a good Idea. I've totally removed RTOS from the app and just added the xheap structure to 3F00000 which tak 5000 of space:

03c00000 l    d  .text    00000000 .text

03c00e10 l    d  .data_icc    00000000 .data_icc

03f00000 l    d  .data_heap    00000000 .data_heap

03c00e14 l    d  .rodata    00000000 .rodata

03c010c0 l    d  .data    00000000 .data

03c010f4 l    d  .bss    00000000 .bss

00000000 l    d  .comment    00000000 .comment

00000000 l    d  .debug_aranges    00000000 .debug_aranges

00000000 l    d  .debug_pubnames    00000000 .debug_pubnames

00000000 l    d  .debug_info    00000000 .debug_info

00000000 l    d  .debug_abbrev    00000000 .debug_abbrev

00000000 l    d  .debug_line    00000000 .debug_line

00000000 l    d  .debug_frame    00000000 .debug_frame

00000000 l    d  .debug_str    00000000 .debug_str

00000000 l    d  .debug_loc    00000000 .debug_loc

00000000 l    d  *ABS*    00000000 .shstrtab

00000000 l    d  *ABS*    00000000 .symtab

00000000 l    d  *ABS*    00000000 .strtab

00000000 l    df *ABS*    00000000 test_ad1836_driver.c

03c00e14 l     O .rodata    0000000e ___func__.4805

03f00000 l     O .data_heap    00005000 _xHeap

so there is still the ad1836 drivcer and interupt but no FREERTOS at all.

I just added in test_ad1836_driver.c:

__attribute__ ((__section__(".data_heap"))) static union xRTOS_HEAP

//static union xRTOS_HEAP                                                     

{

        #if portBYTE_ALIGNMENT == 8

        volatile portDOUBLE dDummy;

        #else

                volatile unsigned long ulDummy;

        #endif

        unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];

} xHeap;

and in the function icc_task_init:

xHeap.ucHeap[0] = 5;

In the compiler I only compile test_ad1836_driver object:

freertos: $(FREERTOSPORTABLE_INCLUDE)/bfin_isr.s $(FREERTOSPORTABLE_INCLUDE)/po\

rtmacro.h $(FREERTOSPORTABLE_INCLUDE)/port.c $(ICC_CORE)

        $(CC) $(CFLAGS)  test_ad1836_driver.c

test_ad1836_driver:$(FREERTOSPORTABLE_INCLUDE)/bfin_isr.s

    $(LD) -v  -o test_ad1836_driver -T  coreb_test_ad1836_driver.lds  --jus\

t-symbol $(ICC_CORE) test_ad1836_driver.o  -Ttext $(TASK_LOAD_BASE) $(LDFLAGS) \

-L /opt/uClinux/bfin-elf/bfin-elf/lib -lc

when I run it I get the same error:

root:/> ./icc_loader -f -e test_ad1836_driver                                 

writing to 0x03c00000, 0x1160    bytes: OK                                    

writsm_debug:sm_find_session bits 00000000 localep 0                          

sm_debug:table bits1 00000000                                                 

sm_debug:table index :table bits2 00000001                                    

sm_debug:create ep index 0 srcep 0 type 2                                     

sm_debug:session 028f3828                                                     

ingsm_debug:sm_send_packet: 0 028f3828                                        

sm_debug:alloc buffer 2941200                                                 

sm_debug:sm_task_sendmsg msg type 2000000                                     

sm_debug:sm_task_sendmsg init addr03c00530                                    

sm_debug:sm_send_packet: len 332 type 2000000 dst 1 dstep 5 src 0 srcep 0     

sm_debug:sm_send_message_internal: dst 1 src 0 02000000                       

sm_debug:send message cpu 1 sent 1                                            

COREB: sm_handle_control_message type 2000000                                 

to 0x03f00000, 0x5000    bytes: OK                                           

task_init_addr 3c00530                                                        

task_exit_addr 3c00cf4                                                        

COREB: sm_handle_control_message 2000000 2000000                              

COREB: task init 3c00530 exit 3c00cf4                                         

COREB: sm_send_message_internal() dst 0 src 1 2000001                         

sm_debug:sm_find_session bits 00000001 localep 0                              

sm_debug:index 0 ,local ep 0 type 2                                           

sm_debug:session 028f3828 index 0 msg type2000001                             

sm_debug:sm_task_recvmsg msg type 2000001                                     

sm_debug:sm_task_recvmsg free 2941200                                         

COREB: finish sm_handle_control_message task status 1                         

COREB: finish1 sm_handle_control_message task status 1                        

COREB: before run task 3c00530                                                

COREB: execption 2c addr 4000000                                              

COREB: execption 2c addr 4000000                                              

COREB: execption 2c addr 4000000    

So at least it show that this specific error is definilty not related to RTOS

thanks,

William

QuoteReplyEditDelete

2011-10-27 01:26:16     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104192   

Hi Steven,

to make sure it is not a problem in my way of implementing icc task, I've used your example task1 and copy past the xheap code and section memory as follow:

in task1.c I added:

.....

#define configTOTAL_HEAP_SIZE           ( ( size_t ) ( 20 * 1024 ) )

__attribute__ ((__section__(".data_heap"))) static union xRTOS_HEAP

//static union xRTOS_HEAP                                                     

{

        #if portBYTE_ALIGNMENT == 8

        volatile portDOUBLE dDummy;

        #else

                volatile unsigned long ulDummy;

        #endif

        unsigned char ucHeap[ configTOTAL_HEAP_SIZE ];

} xHeap;

sm_uint32_t __icc_task_data session_index;

void  icc_task_init(int argc, char *argv[])

{

        xHeap.ucHeap[0] = 5;

in bf561.lds

  /* MEM_ICC : ORIGIN = 0x3C00000, LENGTH = 0x400000*/

  MEM_ICC : ORIGIN = 0x3C00000, LENGTH = 0x300000

  MEM_FREERTOS : ORIGIN = 0x3F00000, LENGTH = 0x100000

in coreb_task.lds:

  .data_icc        :

  {

    *(.icc.data)

  } >MEM_ICC =0

  .data_heap       :

  {

    *(.data_heap)

  } >MEM_FREERTOS =0

the result of bfin-uclinux-objdump -x task1:

03c00274 l    d  .data_icc    00000000 .data_icc

03f00000 l    d  .data_heap    00000000 .data_heap

....

03f00000 l     O .data_heap    00005000 _xHeap

Then when I run it I get the exact same error:

./icc_loader -f -e task1                                              

writing to 0x03c00000, 0x324     bytes: OK                                    

writsm_debug:sm_find_session bits 00000000 localep 0                          

sm_debug:table bits1 00000000                                                 

sm_debug:table indeg:table bits2 00000001                                     

sm_debug:create ep index 0 srcep 0 type 2                                     

sm_debug:session 028f3828                                                     

ingsm_debug:sm_send_packet: 0 028f3828                                        

sm_debug:alloc buffer 2b10a00                                                 

sm_debug:sm_task_sendmsg msg type 2000000                                     

sm_debug:sm_task_sendmsg init addr03c00000                                    

sm_debug:sm_send_packet: len 332 type 2000000 dst 1 dstep 5 src 0 srcep 0     

sm_debug:sm_send_message_internal: dst 1 src 0 02000000                       

sm_debug:send message cpu 1 sent 1                                            

COREB: sm_handle_control_message type 2000000                                 

to 0x03f00000, 0x5000    bytes: OK                                           

task_init_addr 3c00000                                                        

task_exit_addr 3c00254                                                        

COREB: sm_handle_control_message 2000000 2000000                              

COREB: task init 3c00000 exit 3c00254                                         

COREB: sm_send_message_internal() dst 0 src 1 2000001                         

sm_debug:sm_find_session bits 00000001 localep 0                              

sm_debug:index 0 ,local ep 0 type 2                                           

sm_debug:session 028f3828 index 0 msg type2000001                             

sm_debug:sm_task_recvmsg msg type 2000001                                     

sm_debug:sm_task_recvmsg free 2b10a00                                         

COREB: finish sm_handle_control_message task status 1                         

COREB: finish1 sm_handle_control_message task status 1                        

COREB: before run task 3c00000                                                

COREB: execption 2c addr 4000000

.....

So there is clearly something we do wrong when offset the heap to this value even with a minimal task like your example task1.

So what could be at those mem address that stop icc to load task1?

Thanks,

William

QuoteReplyEditDelete

2011-10-27 07:02:22     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104213   

Hi William,

sorry, I found the root cause is a bug of icc_loader, it will memset the memory region to zero before load a program segment but it overwrite the .text section when load the .heap.freertos section. I have updated the icc_loader and now it can load the following test task.

#include <icc.h>

#include <protocol.h>

#include <debug.h>

#define LOCAL_SESSION 5

#define configTOTAL_HEAP_SIZE 10*1024

#if 1

union xRTOP_HEAP {

    unsigned char ucHeap[configTOTAL_HEAP_SIZE];

} xHeap __attribute__((__section__(".heap.freertos")));

#endif

sm_uint32_t __icc_task_data session_index;

void  icc_task_init(int argc, char *argv[])

{

    int i = 0;

    xHeap.ucHeap[0] = 5;

    coreb_msg("dump heap\n");

    for (i = 0; i < 10; i++)

        coreb_msg("%x ",  xHeap.ucHeap[i]);

    while(1)

        icc_wait();

}

-steven

icc_loader

QuoteReplyEditDelete

2011-10-27 09:21:04     Re: CORE B: free RTOS implementation issue COREB: execption

william pagnon (AUSTRALIA)

Message: 104214   

Hi Steven,

great at least that is something fixed.

I tried the new version of icc with task1 it works perfectly. with my app with all freeRTOS removed (but still with ad1836 driver task DMA interput)  It works as well.

Then when I use the version witht the additional FreeRTOS I'm back at the exception:

COREB: execption 2b addr ff700be8

even if I did put the heap at 3f00000:

RTOS/Source/include/../portable/MemMang/heap_2.c

03c03f30 l     O .rodata    00000002 _heapSTRUCT_SIZE

03c04250 l     O .data    00000004 _xFreeBytesRemaining

03c042c0 l     O .bss    00000004 _xHeapHasBeenInitialised.1929

03f00000 l     O .data_heap    00005000 _xHeap

if I do:

bfin-uclinux-addr2line -f -e test_ad1836_driver ff700be8

??

??:0

or

bfin-uclinux-addr2line -f -e icc ff700be8

it is the same, the memory address is not referenced in the binaries.

How I can know where this address come from? It must be something else than the heap array that cause problem.

Thanks,

William

QuoteReplyEditDelete

2011-10-28 02:58:54     Re: CORE B: free RTOS implementation issue COREB: execption

steven miao (CHINA)

Message: 104217   

Hi William,

FYI. Our uclinux forum is going to migrate to analog engineerzone, the blackfin uclinux forum will be closed soon. If you have new question about blackfin uclinux pls create new thread in engineerzone under open-source/linux-blackfin.

  ez.analog.com/community/dsp/open-source/linux-blackfin

-steven

Attachments:
https://ez.analog.com/cfs-file/__key/communityserver-wikis-components-files/00-00-00-01-91/Free_5F00_RTOS_5F00_imp.tar.bz2