Hi all,
I want to modify a data structure for a BF561 application based on current
stable version. What I found is everything goes well as long as the size of the
structure is the same but if I increase the size even one byte, two cores are
halted because of 'unknown exception occurred'.
I checked the LDF file and the structure objects are defined in L1_data_B for
each core. I don't see why DSP only works for old data structure.
Can any one give me some suggestions?
Thanks.
unknown exception occurred after data structure modifed in BF561
Started by ●March 16, 2010
Reply by ●March 16, 20102010-03-16
On Tue, 16 Mar 2010, wzgllc wrote:
> Hi all,
> I want to modify a data structure for a BF561 application based on
>current stable version. What I found is everything goes well as long as
>the size of the structure is the same but if I increase the size even one
>byte, two cores are halted because of 'unknown exception occurred'.
>
> I checked the LDF file and the structure objects are defined in
>L1_data_B for each core. I don't see why DSP only works for old data
>structure.
>
> Can any one give me some suggestions?
Check every line of code that references the structure. There must be
something burried off in far dusty corner that is accessing a pointer
which generates a bad address.
Another idea is to check alignment. What happens if you change the size
by 4 bytes, or if you exactly double the size?
Can you at least find the place in the code where the processor halts? If
it's at startup, then the linker is confused. But if it runs a while,
then it's just a bug in the code.
Patience, persistence, truth,
Dr. mike
> Hi all,
> I want to modify a data structure for a BF561 application based on
>current stable version. What I found is everything goes well as long as
>the size of the structure is the same but if I increase the size even one
>byte, two cores are halted because of 'unknown exception occurred'.
>
> I checked the LDF file and the structure objects are defined in
>L1_data_B for each core. I don't see why DSP only works for old data
>structure.
>
> Can any one give me some suggestions?
Check every line of code that references the structure. There must be
something burried off in far dusty corner that is accessing a pointer
which generates a bad address.
Another idea is to check alignment. What happens if you change the size
by 4 bytes, or if you exactly double the size?
Can you at least find the place in the code where the processor halts? If
it's at startup, then the linker is confused. But if it runs a while,
then it's just a bug in the code.
Patience, persistence, truth,
Dr. mike
Reply by ●March 17, 20102010-03-17
On Tue, 16 Mar 2010, Zhigang Wang wrote:
> Thank you, Dr. mike.
>
> I don't think it happens at startup because two cores can be waiting for the data received from SPI. The trick is only core A handles the SPI DMA ISR but the variables in core B cannot be accessed, so core A is using a pointer defined in shared memory to pass data to core B. Two cores are using the same structure called RFM like this:
> typedef struct _rfm
> {
> unsigned char name[24];
> ...........
> struct B data[10];
> } rfm_t;
> the original sizeof(rfm_t) is 256 and I want to increase data[10] to
>data[24]. If I keep the size 256 and change the size or name of other
>elements (short, int ...) and leave data alone, dsp always works fine.
>But if I change data[10] to data[12] or more, core A crashes first and
>then core B.
>
> I checked the startup code and in the stack initialization there is a
>SP += -12, so do you think it is a stack overflow?
That's a good thing to check. It could also be a heap->stack problem.
When you increase the size of the structure you could be running into the
stack when you weren't before. What is a "struct B"? How many bytes is
one unit of B?
Try getting a memory map and see how things are laid out by the linker.
Then just before you crash look at your pointers. You might get some
clues on where things are going into the weeds.
Patience, persistence, truth,
Dr. mike
> Thank you, Dr. mike.
>
> I don't think it happens at startup because two cores can be waiting for the data received from SPI. The trick is only core A handles the SPI DMA ISR but the variables in core B cannot be accessed, so core A is using a pointer defined in shared memory to pass data to core B. Two cores are using the same structure called RFM like this:
> typedef struct _rfm
> {
> unsigned char name[24];
> ...........
> struct B data[10];
> } rfm_t;
> the original sizeof(rfm_t) is 256 and I want to increase data[10] to
>data[24]. If I keep the size 256 and change the size or name of other
>elements (short, int ...) and leave data alone, dsp always works fine.
>But if I change data[10] to data[12] or more, core A crashes first and
>then core B.
>
> I checked the startup code and in the stack initialization there is a
>SP += -12, so do you think it is a stack overflow?
That's a good thing to check. It could also be a heap->stack problem.
When you increase the size of the structure you could be running into the
stack when you weren't before. What is a "struct B"? How many bytes is
one unit of B?
Try getting a memory map and see how things are laid out by the linker.
Then just before you crash look at your pointers. You might get some
clues on where things are going into the weeds.
Patience, persistence, truth,
Dr. mike
Reply by ●March 17, 20102010-03-17
Thank you, Dr. mike.
I don't think it happens at startup because two cores can be waiting for the data received from SPI. The trick is only core A handles the SPI DMA ISR but the variables in core B cannot be accessed, so core A is using a pointer defined in shared memory to pass data to core B. Two cores are using the same structure called RFM like this:
typedef struct _rfm
{
unsigned char name[24];
...........
struct B data[10];
} rfm_t;
the original sizeof(rfm_t) is 256 and I want to increase data[10] to data[24]. If I keep the size 256 and change the size or name of other elements (short, int ...) and leave data alone, dsp always works fine. But if I change data[10] to data[12] or more, core A crashes first and then core B.
I checked the startup code and in the stack initialization there is a SP += -12, so do you think it is a stack overflow?
Thank you in advance,
Zhigang
From: Mike Rosing
To: wzgllc
Cc: a...
Sent: Tue, March 16, 2010 8:16:00 AM
Subject: Re: [adsp] unknown exception occurred after data structure modifed in BF561
On Tue, 16 Mar 2010, wzgllc wrote:
> Hi all,
> I want to modify a data structure for a BF561 application based on current stable version. What I found is everything goes well as long as the size of the structure is the same but if I increase the size even one byte, two cores are halted because of 'unknown exception occurred'.
>
> I checked the LDF file and the structure objects are defined in L1_data_B for each core. I don't see why DSP only works for old data structure.
>
> Can any one give me some suggestions?
Check every line of code that references the structure. There must be something burried off in far dusty corner that is accessing a pointer which generates a bad address.
Another idea is to check alignment. What happens if you change the size by 4 bytes, or if you exactly double the size?
Can you at least find the place in the code where the processor halts? If it's at startup, then the linker is confused. But if it runs a while, then it's just a bug in the code.
Patience, persistence, truth,
Dr. mike
I don't think it happens at startup because two cores can be waiting for the data received from SPI. The trick is only core A handles the SPI DMA ISR but the variables in core B cannot be accessed, so core A is using a pointer defined in shared memory to pass data to core B. Two cores are using the same structure called RFM like this:
typedef struct _rfm
{
unsigned char name[24];
...........
struct B data[10];
} rfm_t;
the original sizeof(rfm_t) is 256 and I want to increase data[10] to data[24]. If I keep the size 256 and change the size or name of other elements (short, int ...) and leave data alone, dsp always works fine. But if I change data[10] to data[12] or more, core A crashes first and then core B.
I checked the startup code and in the stack initialization there is a SP += -12, so do you think it is a stack overflow?
Thank you in advance,
Zhigang
From: Mike Rosing
To: wzgllc
Cc: a...
Sent: Tue, March 16, 2010 8:16:00 AM
Subject: Re: [adsp] unknown exception occurred after data structure modifed in BF561
On Tue, 16 Mar 2010, wzgllc wrote:
> Hi all,
> I want to modify a data structure for a BF561 application based on current stable version. What I found is everything goes well as long as the size of the structure is the same but if I increase the size even one byte, two cores are halted because of 'unknown exception occurred'.
>
> I checked the LDF file and the structure objects are defined in L1_data_B for each core. I don't see why DSP only works for old data structure.
>
> Can any one give me some suggestions?
Check every line of code that references the structure. There must be something burried off in far dusty corner that is accessing a pointer which generates a bad address.
Another idea is to check alignment. What happens if you change the size by 4 bytes, or if you exactly double the size?
Can you at least find the place in the code where the processor halts? If it's at startup, then the linker is confused. But if it runs a while, then it's just a bug in the code.
Patience, persistence, truth,
Dr. mike
