Gertius Posted October 6, 2006 Report Share Posted October 6, 2006 Hi, fellow MIDIboxers!We are building a relatively complex MIDIbox as a university project, programming it in C, and the due date is nearing very quickly (next monday). I have posted about the project two or three times already, and we will have a detailed wiki explaining everything very soon.Now that our code size has grown and grown (we already migrated to PIC18F4620) we encountered another strange problem yesterday, that we hope to find some help for here.The problem is that function parameters (data type "long" and others) are not transfered correctly into the functions since some days, which leads to very strange behaviour. It means that for example an address for a memory access function is correct before that function is called, but is corrupt inside the function, directly after the call (no calculations done yet in the function). We found out by reading out the values over MIDI before and after the function call. Now we assume that our stack might get an overflow by using too many local variables. Is that probable? How big is the stack exactly? We read about 31 items in the PIC18F4620 datasheet, could that be? How could we read out the stack pointer variable (STKPTR) through inline assembler code to determine if there was an overflow? We would really appreciate some lines of assembler code and how they could be inserted into our C code, as we have no idea of programming assembler.Thanks in advance,Christian Quote Link to comment Share on other sites More sharing options...
ilmenator Posted October 6, 2006 Report Share Posted October 6, 2006 Hi Christian,I don't know about the stack, but you can insert assembler code into C by using the following scheme: ///////////////////////////////////////////////////////////////////////////// // This is an assembly optimized function which scales a 7bit value between // a minimum and maximum value ///////////////////////////////////////////////////////////////////////////// unsigned char Scale_7bit(unsigned char value, unsigned char min, unsigned char max) { // scaled value is (<8-bit random> * ) >> 8 PRODL = value << 1; // 8bit value PRODH = max-min+1; // range __asm movf _PRODL, W mulwf _PRODH, 0 __endasm; return min + PRODH; } This example was taken from the scaling pot values C-example found at http://www.ucapps.de/mios_c_send_range.html.Best regards, ilmenator Quote Link to comment Share on other sites More sharing options...
Gertius Posted October 6, 2006 Author Report Share Posted October 6, 2006 Hi Ilmenator,thanks for your quick answer!We had already found this code example in the assembler page in the wiki though, and we were still not able to figure it out together with the stack...Any other suggestions, anyone?Best regards,Christian Quote Link to comment Share on other sites More sharing options...
ilmenator Posted October 6, 2006 Report Share Posted October 6, 2006 I am quoting the PIC 18F4620 data sheet found at http://ww1.microchip.com/downloads/en/DeviceDoc/39626b.pdf, page 54:5.1.2.1 Top-of-Stack AccessOnly the top of the return address stack (TOS) isreadable and writable. A set of three registers,TOSU:TOSH:TOSL, hold the contents of the stacklocation pointed to by the STKPTR register (Figure 5-2).[glow=red,2,300]This allows users to implement a software stack ifnecessary.[/glow] After a CALL, RCALL or interrupt, thesoftware can read the pushed value by reading theTOSU:TOSH:TOSL registers. These values can beplaced on a user defined software stack. At return time,the software can return these values toTOSU:TOSH:TOSL and do a return.The user must disable the global interrupt enable bitswhile accessing the stack to prevent inadvertent stackcorruption.This does not solve your immediate problem, because you only want to find out if the stack is actually overflowing, but at least you can be sure there is a solution in case that is causing your trouble. I would think there must be some application example from Microchip on how to implement a software stack, but I'm afraid I am not of great help with that.TK to the rescue... :(Best regards, ilmenator Quote Link to comment Share on other sites More sharing options...
stryd_one Posted October 7, 2006 Report Share Posted October 7, 2006 You might wanna take a look at the indispensable sdccman.pdf as well... I've got a vague memory that some of the C stuff uses the stack and might be overwriting your locations.As said above, you could try storing the stack pointers in your own variables at the beginning of the offending function, but I'd also be looking at this sentence closely:The user must disable the global interrupt enable bitswhile accessing the stack to prevent inadvertent stackcorruption.Have you tried disabling interrupts? Quote Link to comment Share on other sites More sharing options...
TK. Posted October 7, 2006 Report Share Posted October 7, 2006 The stack boundaries are defined in the file header of mios_wrapper/mios_wrapper.asm:; the upper boundary of the stacks are defined here ; customize the values for your needs#ifndef STACK_HEAD#define STACK_HEAD 0x37f#endif#ifndef STACK_IRQ_HEAD#define STACK_IRQ_HEAD 0x33f#endif[/code]The default setup is 64 bytes for main tasks, 64 bytes for interrupt tasks. (stack pointer is counted down, there is no collision control to save runtime)Since a PIC18F4620 has enough memory, you could use two 256 bytes stacks located at the upper RAM pages:#define STACK_HEAD 0xeff#define STACK_IRQ_HEAD 0xdffthis should relax the situation.Note that the appr. memory area (0xd00-0xeff) should be reserved in the projekt.lkr fileBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Gertius Posted October 7, 2006 Author Report Share Posted October 7, 2006 TK, you really rescued us!The strangest of bugs are gone with your suggestion, and now we can press on to get rid of the other, more obvious bugs :)Thanks!!!!!!!!!!!!!!!!!!Thanks again to the others who tried to help as well!Best regards,Christian Quote Link to comment Share on other sites More sharing options...
TK. Posted October 8, 2006 Report Share Posted October 8, 2006 Thats great! :)Maybe this hint should be added to the wiki as wellBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.