Program sort of freezes or doesn't after a while when I change something completely unrelated (or so I think)

[samuel.zetterlund]

Hi everyone,

I have a problem I can't sort out. My program runs fine indefinitely if I set one variable in a function at one point but if I don't do that, the program, or at least the debugging stops after a while. The program sort of continues (I can send a few messages from my app to it) but after a while it just doesn't seem to respond.

So.

I added a debug print of "." in the main loop which has a 500ms delay in it. These are some startup messages I get when the program runs fine. The dots just keeps going.

app_timer: RTC: initialized!
 app: Erasing flash page
 app: --> Event received: erased 1 page from address 0x7F000.
 app: Converting a program to a buffer
 app: --> Event received: wrote 112 bytes at address 0x7F000.
 app: Converting a buffer to a program
 app: Accelerometers initialized. 25
 app: Accelerometers initialized. 24
 app: State --> NOT_CONNECTED
 app: end
..................................................................................................................

The dots just keeps going and going.

BUT! If I don't make that function call and set that variable the debugging (and parts of the program) stops after exactly the same amount of time every time:

 app_timer: RTC: initialized!
 app: Erasing flash page
 app: --> Event received: erased 1 page from address 0x7F000.
 app: Converting a program to a buffer
 app: --> Event received: wrote 112 bytes at address 0x7F000.
 app: Converting a buffer to a program
 app: Accelerometers initialized. 25
 app: Accelerometers initialized. 24
 app: State --> NOT_CONNECTED
 app: end
....................

Compare the number of dots in the two examples.

The weird thing now is that the difference is in the beginning of main.c. If I make a function call to a function located in an included file called:

set_potentiometer_resistance(&m_twi_1, DIGITAL_POT_I2C_ADDRESS_MAX5434, 25000);

In that function I only do this:

ret_code_t set_potentiometer_resistance(nrf_drv_twi_t const * p_instance, uint8_t address, int32_t resistance) {
    actual_potentiometer_resistance = resistance;
    ret_code_t err_code;
//    uint8_t payload[2];
//    payload[0] = DIGITAL_POT_MAX5434_COMMAND_VREG;
//    payload[1] = get_potentiometer_tap_position_from_resistance(resistance);
//    
//    err_code = nrf_drv_twi_tx(p_instance, address, &payload, sizeof(payload), false);
    return err_code;
}

The actual_potentiometer_resistance variable is placed in the header file of the potentiometer function.

static int32_t actual_potentiometer_resistance;

I can set it to zero, it works just as well. But if I try to set the value of that variable instead of calling the function, like this:

actual_potentiometer_resistance = 0;
instead of:

set_potentiometer_resistance(&m_twi_1, DIGITAL_POT_I2C_ADDRESS_MAX5434, 25000);

It doesn't work. It stops after the same amount of time.


I can't understund this behavior. It feels like I'm changing something totally unrelated. When I've had similar issues earlier, if the program stops after a while or the debugging stops after a while, all of those problems have been due to me not freeing a malloc:ed variable or so. But what could cause this?

Thanks in advance,
Samuel

[samuel.zetterlund]

Hi again,

I know this is super hard to answer.

Just wanted to add a few things. The program doesn't freeze actually, it's just the printing in the console window that stops.

I've tried renaming the variable and it doesn't change the behavior. I've placed the variable in a different included file and then the debug freezes. I've tried to remove the variable and that won't work.

So the program needs this specific variable (name can be changed) placed in this specific header (or source, tried that as well) file to not continue print debug messages. I can also change the name of the function with the same result. I just need to set this variable to some value for the debugging to work continuously...

I've also tried another board as well as cleaned the project and so on. Same result.

[Karl Ylvisaker]

Hello Samuel,

My program runs fine indefinitely if I set one variable in a function at one point but if I don't do that, the program, or at least the debugging stops after a while. The program sort of continues (I can send a few messages from my app to it) but after a while it just doesn't seem to respond.

Keep in mind that I do not know anything other than this description and code snippets of them, when reading the rest of my answer.

BUT! If I don't make that function call and set that variable the debugging (and parts of the program) stops after exactly the same amount of time every time

This would lead me to believe that the change of "the variable" might not be the cause of your issue.

But what could cause this?

In truth, I have little to no idea - since I have seen a total of 3 lines of un-commented code. There is a multiple of reasons that could be causing an issue here, and I am not sure I understand your issue correctly either.

With my limited insight into your application/project, I am seeing this as an embedded programming issue, more than an nRF issue.
I am not sure I understand your issue correctly, but it seems to me that your trouble is with changing the "actual_potentiometer_resistance" variable, which you have placed as a static variable in the potentiometer header file. 
This is bad C practice, because static global variables are not passed to the linker.
Please see this stackoverflow question on the matter for further detail.

For me to be able to help you more with this issue it would be highly beneficial if you could share more of your code, along with an explanation of what you are trying to achieve - and how the applications behavior differs from what you would have expected.
With this information, I would be better equipped to help you.

As a side note, it is good practice that you are using the "insert" format possibilities in your ticket - but the ticket currently is very hard to read and understand what is part of your reflection and comments in between the code. For future reference it would be greatly beneficial if the ticket was easier to read, for us to better be able to quickly understand your issue.

Looking forward to resolving this issue together!

Best regards,
Karl

 

 

[Karl Ylvisaker]

Hello again,

samuel.zetterlund said:

I know this is super hard to answer.

Yes, but if you provide me with the information I requested in my other comment, then we may start attempting to resolve your issue.
I am looking forward to hearing back from you on that!

samuel.zetterlund said:

Just wanted to add a few things. The program doesn't freeze actually, it's just the printing in the console window that stops.

Thank you for the update - I am glad you were able to verify that the program does not crash.

samuel.zetterlund said:

I've tried renaming the variable and it doesn't change the behavior.

I would not expect the variable name to matter here, but I think its declaration and the placement of the declaration might contribute to the unexpected behavior.

Best regards,
Karl

P.S If you are worried about Intellectual property when sharing code, I may convert this ticket to a private ticket which is only viewable to you and the support staff here at Nordic Semiconductor. Please let me know if you would like me to do this.

[samuel.zetterlund]

Hi Karl.

Thanks so much for your reply. I'll try to be more detailed about this in my next post. I just wanted to thank you for your time and the link to the stackoverflow page. I'll follow that example to improve my code.

Regarding the formatting, I saw that the formatting was completely messed up and tried to change it but didn't manage but I'll be more careful next time.

[Karl Ylvisaker]

Hello again Samuel,

samuel.zetterlund said:

Thanks so much for your reply.

 No problem at all, I am happy to help!

samuel.zetterlund said:

I'll try to be more detailed about this in my next post. I just wanted to thank you for your time and the link to the stackoverflow page. I'll follow that example to improve my code.

Great, I am happy to hear that you found the link useful. There are many pitfalls with embedded C programming, and this issue is certainly one of them.

samuel.zetterlund said:

Regarding the formatting, I saw that the formatting was completely messed up and tried to change it but didn't manage but I'll be more careful next time.

Oh, I understand. I think a certain font might trigger some unexpected behavior. I think this can be resolved by using the "insert" option to add a text box, but I am not entirely sure as I have not tried it myself.
Reading over my own comments again I see that I might have come across as crass  - know that this was not my intention at all!

Looking forward to hearing from you,

Best regards,
Karl