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
Microchip Pic32 exception: ???
Started by ●September 26, 2011
Reply by ●September 26, 20112011-09-26
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 > ClaudioHave you tried the microchip pic32 forum? http://www.microchip.com/forums/Default.aspx?
Reply by ●September 26, 20112011-09-26
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
Reply by ●September 26, 20112011-09-26
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.
Reply by ●September 26, 20112011-09-26
> 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.
Reply by ●September 30, 20112011-09-30
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
Reply by ●September 30, 20112011-09-30
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
Reply by ●September 30, 20112011-09-30
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
Reply by ●September 30, 20112011-09-30
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
Reply by ●September 30, 20112011-09-30
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