Microchip Pic32 exception: ???

Hi.
I'm trying to understand the Pic32 (a decade of familiarity with Pic16 
and Pic18).
I got myself an Ethernet Starter Kit.
The demos run, and I have been able to edit them.
So I tried to get two stacks working together.
I then proceeded merging the TCPIP demo and the USB MSD demo.
The latter just looks for a pendrive and when it sees it a simple text 
file gets written.
The TCPIP integrates a basic http webserver.
By themselves I'm able to run them.
I merged the source files, integrating the USB stack calls in the main 
loop after the TCPIP stack calls.
Fact is the compilation goes through but upon running, code gets stuck.
Initialization goes through until the MAC init, at line 238 of 
ETHPIC32IntMac.c there is this line

if(EthDescriptorsPoolAdd(EMAC_TX_DESCRIPTORS, ETH_DCPT_TYPE_TX, 
_MacAllocCallback, 0)!=EMAC_TX_DESCRIPTORS)

this one apparently fails and I have no clue why.
EMAC_TX_DESCRIPTORS are defines, but ETH_DCPT_TYPE_TX is nowhere to be 
found, as well as the EthDescriptorsPoolAdd function.
Fact is they are nowhere to be found even in the demo project that 
works!

After that the code falls down to the main exception handler

	void _general_exception_handler(unsigned cause, unsigned status)
	{
		Nop();
		Nop();
	}


codes are

cause = 0x10800034
status = 0x00100003 

which I can't find anywhere.
Now the exception handler description suggests that a read/write 
operation was issued on a NULL pointer, or that the stack was 
overflowed.

But the function looks to be asking for memory allocation, and infact 
it's a calloc that fails.
But then even increasing the HEAP size doesn't make it.
The project compiles, it runs without getting stuck, but every function 
calling on the MAC interface fails. As if the pointer is wrong or there 
is no MAC interface instanced.

I really don't know where to look.
Can you suggest me a course of action?

Thanks
Claudio

On Sep 26, 2:43=A0pm, Claude <j...@turturro.com> wrote:
> Hi.
> I'm trying to understand the Pic32 (a decade of familiarity with Pic16
> and Pic18).
> I got myself an Ethernet Starter Kit.
> The demos run, and I have been able to edit them.
> So I tried to get two stacks working together.
> I then proceeded merging the TCPIP demo and the USB MSD demo.
> The latter just looks for a pendrive and when it sees it a simple text
> file gets written.
> The TCPIP integrates a basic http webserver.
> By themselves I'm able to run them.
> I merged the source files, integrating the USB stack calls in the main
> loop after the TCPIP stack calls.
> Fact is the compilation goes through but upon running, code gets stuck.
> Initialization goes through until the MAC init, at line 238 of
> ETHPIC32IntMac.c there is this line
>
> if(EthDescriptorsPoolAdd(EMAC_TX_DESCRIPTORS, ETH_DCPT_TYPE_TX,
> _MacAllocCallback, 0)!=3DEMAC_TX_DESCRIPTORS)
>
> this one apparently fails and I have no clue why.
> EMAC_TX_DESCRIPTORS are defines, but ETH_DCPT_TYPE_TX is nowhere to be
> found, as well as the EthDescriptorsPoolAdd function.
> Fact is they are nowhere to be found even in the demo project that
> works!
>
> After that the code falls down to the main exception handler
>
> =A0 =A0 =A0 =A0 void _general_exception_handler(unsigned cause, unsigned =
status)
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Nop();
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Nop();
> =A0 =A0 =A0 =A0 }
>
> codes are
>
> cause =3D 0x10800034
> status =3D 0x00100003
>
> which I can't find anywhere.
> Now the exception handler description suggests that a read/write
> operation was issued on a NULL pointer, or that the stack was
> overflowed.
>
> But the function looks to be asking for memory allocation, and infact
> it's a calloc that fails.
> But then even increasing the HEAP size doesn't make it.
> The project compiles, it runs without getting stuck, but every function
> calling on the MAC interface fails. As if the pointer is wrong or there
> is no MAC interface instanced.
>
> I really don't know where to look.
> Can you suggest me a course of action?
>
> Thanks
> Claudio

Have you tried the microchip pic32 forum?
http://www.microchip.com/forums/Default.aspx?

Hi Claudio,

On 9/26/2011 5:43 AM, Claude wrote:

[much elided]

> The demos run, and I have been able to edit them.

> By themselves I'm able to run them.

> Fact is the compilation goes through but upon running, code gets stuck.
> Initialization goes through until the MAC init, at line 238 of
> ETHPIC32IntMac.c there is this line
>
> if(EthDescriptorsPoolAdd(EMAC_TX_DESCRIPTORS, ETH_DCPT_TYPE_TX,
> _MacAllocCallback, 0)!=EMAC_TX_DESCRIPTORS)
>
> this one apparently fails and I have no clue why.
> EMAC_TX_DESCRIPTORS are defines, but ETH_DCPT_TYPE_TX is nowhere to be
> found, as well as the EthDescriptorsPoolAdd function.
> Fact is they are nowhere to be found even in the demo project that
> works!

You are *sure* this statement is being compiled in the demo
project(s)?  If so, then ETH_DCPT_TYPE_TX *is* somewhere -- along
with EthDescriptorsPoolAdd().  Look harder.  :>

> Now the exception handler description suggests that a read/write
> operation was issued on a NULL pointer, or that the stack was
> overflowed.

You should be able to examine the stack pointer as well as the
stack's contents.

> But the function looks to be asking for memory allocation, and infact
> it's a calloc that fails.

Are either the size or number of elements *0*?
Alternatively, are either of these "extraordinarily *big*" values?

> But then even increasing the HEAP size doesn't make it.

You sound like you're just poking the code with a stick instead
of trying to *identify* what it is actually doing.  IME, that's
a terribly inefficient and ineffective debugging technique.  :<

> The project compiles, it runs without getting stuck, but every function
> calling on the MAC interface fails. As if the pointer is wrong or there
> is no MAC interface instanced.
>
> I really don't know where to look.
> Can you suggest me a course of action?

Does your IDE allow you to cross-reference symbols?  (i.e.,
to chase down the above)

Do you have a recursive grep(1) available?

Can you *step* through the code to see where it tries to
go (then look at the link map to see what is actually *there*)?

The machine does what it is *told*.  Figure out what it is
being *told* to do and you will have a better insight into
why it isn't doing what you *think* it should!

HTH

On Sep 26, 7:43=A0am, Claude <j...@turturro.com> wrote:
> Hi.
> I'm trying to understand the Pic32 (a decade of familiarity with Pic16
> and Pic18).
> I got myself an Ethernet Starter Kit.
> The demos run, and I have been able to edit them.
> So I tried to get two stacks working together.
> I then proceeded merging the TCPIP demo and the USB MSD demo.
> The latter just looks for a pendrive and when it sees it a simple text
> file gets written.
> The TCPIP integrates a basic http webserver.
> By themselves I'm able to run them.
> I merged the source files, integrating the USB stack calls in the main
> loop after the TCPIP stack calls.
> Fact is the compilation goes through but upon running, code gets stuck.
> Initialization goes through until the MAC init, at line 238 of
> ETHPIC32IntMac.c there is this line
>
> if(EthDescriptorsPoolAdd(EMAC_TX_DESCRIPTORS, ETH_DCPT_TYPE_TX,
> _MacAllocCallback, 0)!=3DEMAC_TX_DESCRIPTORS)
>
> this one apparently fails and I have no clue why.
> EMAC_TX_DESCRIPTORS are defines, but ETH_DCPT_TYPE_TX is nowhere to be
> found, as well as the EthDescriptorsPoolAdd function.
> Fact is they are nowhere to be found even in the demo project that
> works!
>
> After that the code falls down to the main exception handler
>
> =A0 =A0 =A0 =A0 void _general_exception_handler(unsigned cause, unsigned =
status)
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Nop();
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Nop();
> =A0 =A0 =A0 =A0 }
>
> codes are
>
> cause =3D 0x10800034
> status =3D 0x00100003
>
> which I can't find anywhere.
> Now the exception handler description suggests that a read/write
> operation was issued on a NULL pointer, or that the stack was
> overflowed.
>
> But the function looks to be asking for memory allocation, and infact
> it's a calloc that fails.
> But then even increasing the HEAP size doesn't make it.
> The project compiles, it runs without getting stuck, but every function
> calling on the MAC interface fails. As if the pointer is wrong or there
> is no MAC interface instanced.
>
> I really don't know where to look.
> Can you suggest me a course of action?
>
> Thanks
> Claudio

<disclaimer - I don't know how this code works and I've never used
PIC32, but I have done a lot of MIPS in the old days...>

cause and status are defined by the MIPS architecture.  Google 'MIPS32
architecture for programmers' and look in volume III under the chapter
for exceptions.  It's useful to look at the address in the EPC - that
should be where the fault occurred.  In this case it looks like a trap
exception.

When an exception happens the software exception handler is in charge
of storing off the registers (except cause, status, and EPC), so you
need to know how that works to decode the state of the registers and
the register save area.

> if(EthDescriptorsPoolAdd(EMAC_TX_DESCRIPTORS, ETH_DCPT_TYPE_TX,
> _MacAllocCallback, 0)!=EMAC_TX_DESCRIPTORS)
>
> this one apparently fails and I have no clue why.
> EMAC_TX_DESCRIPTORS are defines, but ETH_DCPT_TYPE_TX is nowhere to be
> found, as well as the EthDescriptorsPoolAdd function.
> Fact is they are nowhere to be found even in the demo project that
> works!

ETH_DCPT_TYPE is defined as 0x2 in:
Microchip/MPLAB C32 Suite/pic32-libs/include/peripheral/eth.h

EthDescriptorsPoolAdd is in the application library that links in from
the compiler library.  It's there somewhere.

In article <21ea1525-2fac-43e3-ad12-
9d008d4ff7be@u6g2000vbo.googlegroups.com>, amdyer@gmail.com says...

> <disclaimer - I don't know how this code works and I've never used
> PIC32, but I have done a lot of MIPS in the old days...>
> 
> cause and status are defined by the MIPS architecture.  Google 'MIPS32
> architecture for programmers' and look in volume III under the chapter
> for exceptions.  It's useful to look at the address in the EPC - that
> should be where the fault occurred.  In this case it looks like a trap
> exception.
> 
> When an exception happens the software exception handler is in charge
> of storing off the registers (except cause, status, and EPC), so you
> need to know how that works to decode the state of the registers and
> the register save area.

Thank you very much, it looks like usefull information.
I'll check it.

Claudio

In article <2d376165-1135-48c1-8b30-930427359e86
@x19g2000vbl.googlegroups.com>, robertgush@gmail.com says...

> Have you tried the microchip pic32 forum?
> http://www.microchip.com/forums/Default.aspx?


Been there, done that.
Those forums are pretty much useless.

Claudio

In article <j5q5pa$hq5$1@speranza.aioe.org>, nowhere@here.com says...
Thank you DonY, your has been the most usefull post till now.

> You are *sure* this statement is being compiled in the demo
> project(s)?  If so, then ETH_DCPT_TYPE_TX *is* somewhere -- along
> with EthDescriptorsPoolAdd().  Look harder.  :>


Will comply...


> You should be able to examine the stack pointer as well as the
> stack's contents.

Yes I should, but I'm a bit unfamiliar with this kind of low level 
debugging.

 
> Are either the size or number of elements *0*?
> Alternatively, are either of these "extraordinarily *big*" values?

It didn't look like it, but I will check again.

> You sound like you're just poking the code with a stick instead
> of trying to *identify* what it is actually doing.  IME, that's
> a terribly inefficient and ineffective debugging technique.  :<

Yes I know, but the complete stack source code is 7 MB and it's almost 
undocumented. Meaning that even if there are comments in the functions, 
there are no documents clearle explainig the layout of the stack, the 
various module, who's on top of whom, and who talks to whom.

> Does your IDE allow you to cross-reference symbols?  (i.e.,
> to chase down the above)
> 
> Do you have a recursive grep(1) available?

If you mean stepping backwards then no.
And no grep, there is no OS beneath this, it's purely microcontroller 
work.

> Can you *step* through the code to see where it tries to
> go (then look at the link map to see what is actually *there*)?

Yes and it jumps.
I can follow through to the incriminated calloc I mentioned, then since 
it's implementation isn't available as source, it steps though some asm 
garbage I can't comprehend (I never learned asm) and then arrives to the 
asm equivalent of the exception handler.

> The machine does what it is *told*.  Figure out what it is
> being *told* to do and you will have a better insight into
> why it isn't doing what you *think* it should!
> 

Yeah, know it pretty well.
Luckily it's not my first project ;)

Claudio

In article <MPG.28eff61bb9d67b06989683@news.tiscali.it>, 
erupter@tiscali.it says...
> > Do you have a recursive grep(1) available?
> 
> And no grep, there is no OS beneath this, it's purely microcontroller 
> work.

My bad.
I'm under windows, I can search whatever file I want.
I'm not clear on the recursive grep... 
Literally no, but anyway what would you want me to search in such a way?

The IDE offers a project-wide text search, so I can look in any 
explicitely included file.
That means though that if a file gets included deep in another file, and 
not explicitely in the project, the search won't go through it.

Claudio

On Sep 30, 7:52=A0am, Claude <erup...@tiscali.it> wrote:
> In article <j5q5pa$hq...@speranza.aioe.org>, nowh...@here.com says...
> Thank you DonY, your has been the most usefull post till now.
>
> > You are *sure* this statement is being compiled in the demo
> > project(s)? =A0If so, then ETH_DCPT_TYPE_TX *is* somewhere -- along
> > with EthDescriptorsPoolAdd(). =A0Look harder. =A0:>
>
> Will comply...
>
> > You should be able to examine the stack pointer as well as the
> > stack's contents.
>
> Yes I should, but I'm a bit unfamiliar with this kind of low level
> debugging.
>
> > Are either the size or number of elements *0*?
> > Alternatively, are either of these "extraordinarily *big*" values?
>
> It didn't look like it, but I will check again.
>
> > You sound like you're just poking the code with a stick instead
> > of trying to *identify* what it is actually doing. =A0IME, that's
> > a terribly inefficient and ineffective debugging technique. =A0:<
>
> Yes I know, but the complete stack source code is 7 MB and it's almost
> undocumented. Meaning that even if there are comments in the functions,
> there are no documents clearle explainig the layout of the stack, the
> various module, who's on top of whom, and who talks to whom.
>
> > Does your IDE allow you to cross-reference symbols? =A0(i.e.,
> > to chase down the above)
>
> > Do you have a recursive grep(1) available?
>
> If you mean stepping backwards then no.
> And no grep, there is no OS beneath this, it's purely microcontroller
> work.

Did you look at my post?  I already did a "find ./Microchip -exec grep
ETH_DCPT_TYPE_TX {} ;" on the compiler tree.  It's defined as 0x2 in
Microchip/MPLAB C32 Suite/pic32-libs/include/peripheral/eth.h