Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 5 months ago.
Code stuck!
Hello:
I downloaded this code for IAR and have it running on an Nucleo F103RB board. It runs well, and I can receive packets to a Lora network (I am using a MultiConnect Conduit). However, sometimes the code freezes!
Debuggin on IAR, it seems that it is getting stuck on "static u2_t deltaticks( u4_t time )" on hal.c. It is getting the time from "u4_t hal_ticks( void )". The problem is that function is getting stuck with an incorrect time, so the time count never advances and the MCU is stuck on this function.
It seems that this happens because timer.read_us() is getting stuck on a value. Since this function is compiled I cannot see what is going inside...What I can only see is that the time returned just loops back, refusing to go over a certain value. Here are example values of succesive "timer.read_us()" calls when it gets stuck:
1.) 1669026 2.) 1673646 3.) 1692942 4.) 1635976 5.)1639285 ...
It seems as it loops back when trying to go over 1700000...
If I change variables in the debugger to continue with the program the program runs fine for a while, but eventually gets this problem again!
Question relating to:
Update: The values of timer.read_us() when the code gets stuck can vary. I got values near 7000k
posted by Eduardo Garcia 24 Nov 2015I fixed it via a "hack" that I do not like, but it was the only way I saw to fix my problem without being able to see what was going inside "time.read_us()".
I defined a global variable called "last_d" and checked that the count of time was always decreasing (it would not decrease but increase when this bug presented itself). Of course, this cuts some time off the wait. I also changed the following function as follows:
static u2_t deltaticks( u4_t time ) {
u4_t t = hal_ticks( ); s4_t d = time - t;
if(d <= last_d) { last_d = d; }else { last_d = 254; last_d = last_d << 23; d = 0; }
if( d <= 0 ) { last_d = 254; last_d = last_d << 23; return 0; in the past } if( ( d >> 16 ) != 0 ) { return 0xFFFF; far ahead } return ( u2_t )d; }
The reload of last_d inside the "else" was done because I was getting a hard fault if I reloaded directly last_d with a really big number. This way, uploading a byte and shifting it, did not get me a hard fault...
I am trying this code, by no means I recommend it as a fix. For me it seems that timer.read_us() is behaving weird.
I have the code downloaded to IAR with optimization level 0.
posted by Eduardo Garcia 25 Nov 2015The code is still getting stuck. I believe there may be an issue with time.read_us() on the Nucleo boards! Has somebody else experienced the same problem?
posted by Eduardo Garcia 02 Dec 2015