Hi guys

I got this very strange things, I don't know why, any thought?

I am using XC16 v1.35 free, PIC24FJ128G610, single partition mode, code size just over 51%, thanks guys!

void func_1(void){

  // lots of other codes

  code_1; // this line work
  code_2; // this line work
}

// this function is not call anywhere
// if the codes are comment out, the func_1() work
void func_2(void){
  //other_code_1;
  //other_code_2;
}

void func_1(void){

  // lots of other codes

  code_1; // this line DO NOT work
  code_2; // this line DO NOT work
}

// this function is not call anywhere
// if the codes are NOT comment out, the func_1()  DO NOT wok
void func_2(void){
  other_code_1;
  other_code_2;
}

 

Hi guys

I got this very strange things, I don't know why, any thought?

I am using XC16 v1.35 free, PIC24FJ128G610, single partition mode, code size just over 51%, thanks guys!

void func_1(void){

  // lots of other codes

  code_1; // this line work
  code_2; // this line work
}

// this function is not call anywhere
// if the codes are comment out, the func_1() work
void func_2(void){
  //other_code_1;
  //other_code_2;
}

void func_1(void){

  // lots of other codes

  code_1; // this line DO NOT work
  code_2; // this line DO NOT work
}

// this function is not call anywhere
// if the codes are NOT comment out, the func_1()  DO NOT wok
void func_2(void){
  other_code_1;
  other_code_2;
}

reported

 

Not sure what you are asking, @bug13 Sleep on it?

 

Not sure what you are asking, @bug13 Sleep on it?

So say I have a function like this working fine:

void func_1(){
  printf("hello world!\n");
}

Then and I need write another function for other stuff:

void func_2(){
  printf("do other stuff.\n");
}

Two functions can work independently, not depending on each other. But for some reason, after writing func_2(), func_1() stop working. The thing is, func_2() is not call anywhere. But if I remove func_2(), func_1() start working again.

I have no compiler error.

The above is just a simple example, but in my case, I simply can not write more code, as if I wrote more code, my other part of the code stop working. It doesn't matter what my code is.

PS: not using pointer at those function, no access hardware. Just simple calculation

 

reported

???

 

No idea what's happening without a complete code example demonstrating the problem. Have you tried XC16 V1.36B? Enable additional and ANSI warning in the xc16 -gcc 'Preprocessing and messages' menu to see if anything strange is happening other than GCC ISO 90 warnings.
Just a WAG, do you have nested functions?
https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

 

I run into same type of problems in the past solved them by putting returns at the end of a function.
Seems to be related to stack manipulation. However I am not sure about that.

Function();
{
bla bla
return;
}
Give it a try it might work for you.

Picbuster

 

No idea what's happening without a complete code example demonstrating the problem. Have you tried XC16 V1.36B? Enable additional and ANSI warning in the xc16 -gcc 'Preprocessing and messages' menu to see if anything strange is happening other than GCC ISO 90 warnings.
Just a WAG, do you have nested functions?
https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

I have tried these:

• upgrade to xc16 v1.36B, didn't fix it
• I have no nested function

I have attached the warnings after enabling strict ANSI warnings, just in case you want to have a look.

These are the none ISO C90 warnings after enabling strict ANSI warnings:

• uart.c:17:24: warning: binary constants are a GCC extension, [my uarts working fine, so not this??]
• virtual_callpoint.h:227:13: warning: type of bit-field 'eeprom_error' is a GCC extension, [this is just a flag waiting to be implement, not doing anything yet]
• utilities.c:25:46: warning: wrong type argument to increment, [this part work, it's a void *ptr, cast to correct pointer then increment]

If you want to, I can email you the full source code to have a look.

Something to do with stack?? This is my first PIC24

 

I run into same type of problems in the past solved them by putting returns at the end of a function.
Seems to be related to stack manipulation. However I am not sure about that.

Function();
{
bla bla
return;
}
Give it a try it might work for you.

Picbuster

I have added a return to all void return function, still no luck

 

I have tried these:

• upgrade to xc16 v1.36B, didn't fix it
• I have no nested function

I have attached the warnings after enabling strict ANSI warnings, just in case you want to have a look.

These are the none ISO C90 warnings after enabling strict ANSI warnings:

• uart.c:17:24: warning: binary constants are a GCC extension, [my uarts working fine, so not this??]
• virtual_callpoint.h:227:13: warning: type of bit-field 'eeprom_error' is a GCC extension, [this is just a flag waiting to be implement, not doing anything yet]
• utilities.c:25:46: warning: wrong type argument to increment, [this part work, it's a void *ptr, cast to correct pointer then increment]

If you want to, I can email you the full source code to have a look.

Something to do with stack?? This is my first PIC24

Turn optimization to 0 and set the load symbols option. Search for the problem function(s) in the listing at Window/Debugging/Output/Disassm listing. Examine for calls to the functions under your GO/NOGO testing conditions.

 

Turn optimization to 0 and set the load symbols option. Search for the problem function(s) in the listing at Window/Debugging/Output/Disassm listing. Examine for calls to the functions under your GO/NOGO testing conditions.

This is very interesting, I can see the function is there, but it just won't do anything in my NOGO condition, it look like some codes are skipped. Any other thoughts??

 

One more thing, for the code that work, it only work on power cycle. If I use asm("reset") instruction, the working code will stop working... more strange....

eg, same code:

• cold power cycle, work
• use asm("reset"), doesn't work

 

One more thing, for the code that work, it only work on power cycle. If I use asm("reset") instruction, the working code will stop working... more strange....

eg, same code:

• cold power cycle, work
• use asm("reset"), doesn't work

Looks like a run-time error caused by memory corruption, like the stack or data memory is getting stomped on somewhere. Stack overflow, Divide-by-zero, Non-existent interrupt routine, Non-existent trap routine, Function pointer failure, Invalid/negative array index, too large of a data array in program memory, bad pointer usage can all cause undefined behaviors.
What type of board are you using? Are you sure the hardware side is good? Clock source configuration, power and bypassing.

http://ww1.microchip.com/downloads/en/DeviceDoc/39712a.pdf

Most of the special function registers (SFRs) associated with the PIC24F CPU and peripherals are reset to a particular value at a device Reset. The SFRs are grouped by their peripheral or CPU function and their Reset values are specified in the corresponding section of this manual. The Reset value for each SFR does not depend on the type of Reset, with the exception of two registers. The Reset value for the Reset Control register, RCON, will depend on the type of device Reset. The Reset value for the Oscillator Control register, OSCCON, will depend on the type of Reset and the programmed values of the oscillator Configuration bits in the FOSC Device Configuration register (see Table 7-1).

 

Looks like a run-time error caused by memory corruption, like the stack or data memory is getting stomped on somewhere. Stack overflow, Divide-by-zero, Non-existent interrupt routine, Non-existent trap routine, Function pointer failure, Invalid/negative array index, too large of a data array in program memory, bad pointer usage can all cause undefined behaviors.
What type of board are you using? Are you sure the hardware side is good? Clock source configuration, power and bypassing.

http://ww1.microchip.com/downloads/en/DeviceDoc/39712a.pdf

Hi @nsaspook, thanks for your guidance, I think I may found the problem. I think I didn't disable interrupt when reading/writing flash memory. I will see if it still work in the next couple of days.

Turn optimization to 0 and set the load symbols option

I think I will use this method you show me more and more in the future, thanks for your help.

 

It turns out its more than that, the problem seem to be I disabled the nesting interrupt and using IPL<2:0> to disable the global interrupt at the same time.

Datasheet here:
http://ww1.microchip.com/downloads/en/devicedoc/39707a.pdf

Ref: 8.2.4.2 INTERRUPT NESTING

The IPL<2:0> bits become read-only when interrupt nesting is disabled. This prevents the user software from setting IPL<2:0> to a lower value which would effectively re-enable interrupt nesting.