Hi, I have quite big program on my RCM5700. Its basically a webserver listening for connection request from a web enabled phone. As of now, it only has one peripheral (connected to an RF transceiver via SPI serial port B)
My problem is, the behavior of my program is very unpredictable. Just to let you know, its timing sensitive (sending and receiving of data via the RF transceiver must occur in a certain time frame)
Anyway, there are times that the program works flawlessly. Next time you know, (maybe after a restart of my computer where the RCM5700 is connected via USB power), the program doesn’t work. And I haven’t changed a thing in the code.
And also, running with programming mode (jumper JP1 1&2 connected) doesn’t yield the same behavior as running it in standalone mode(jumper JP1 1&2 disconnected). I make sure that in the timing critical section of my code, there are no printfs or whatever that can alter execution time between commands.
There are times where I can make it work during programming mode but when I try to power it up in standalone mode, it doesn’t work like its supposed to be.
Any idea what might be causing all these troubles?
My SPI transceiver is connected via the prototyping board’s 3.3V and uses a maximum of 23mA
If you are using program loops to do timing or relying on measuring time of execution of code to ensure timing you will run into problems when shifting between programming mode and stand alone mode - also when shifting between compiling with debug enebled and compiling without debug as the compiler inserts RST 0x28 instructions into each line od C code in debug mode.
When running debug enabled code in stand alone mode the time taken to execute the RST 0x28 instructions will be different than when in debug mode.
You should look at using timers to organise the timing if possible. The options avaliable depend on the sort of time scales you are talking about.
Regards,
Peter
Hi, thank you for your help. Now I know why my minicore is behaving. I was able to fix my problem by identifying any time critical code with nodebug so that it behaves the same whether in programmming or stand-alone mode. I just started in Dynamic C so I haven’t yet seen all the features it offer. Didn’t know about the debugging RST etc before and thanks to you, now I know.
By the way, timing is in the 10ms range but each communication between RF transceivers must occur before the HTTP timeout happens or the Android app im developing crashes
okay, this is getting harder than i thought. So i used the nodebug declaration on each routine that seems to work. Did a debug compile, test my program and it works as intended.
did another compile, this time without debugging . Compiled correctly, unplugged the rabbit, remove the jp1 jumper to enable RUN mode. everything works as intended.
time for bed, unplugged rabbit from usb, turned off my computer and off to bed.
next morning, got up, turn my computer ON, plugged the rabbit in USB (still in RUN mode jumper), tested and boink, it doesn’t work.
it was working the previous night and i haven’t changed a thing except unplugged it from the computer (via USB to turn it OFF).
can you guys please tell me what’s going on here. the behavior is random and there’s no way a product that behaves like this is going to make it in the market.
It’s hard to be specific in a case like this but for me the most common cause of erratic behaviour on start up is failure to initialise variables. The random nature of what can end up in memory can lead to weird failures as things in the code respond to unexpected values in flags and tables etc.
Very brief power downs can leave the memory mostly the same as before due to residual charge and longer power downs can cause much more random contents. It’s worth checking that you have everything set to known values on power up if you have not got battery backed RAM.
Regards,
Peter
Thanks Peter for the reply
After doing some line by line extensive review on my code, I think I finally nailed the source of my problem. It seems like the I/O port cant seem to provide enough power for my transceiver to function properly. It was initially part of my code to power cycle the transceiver by toggling one of the I/O pin connected to the transceiver as a Vcc source. Now that I have connected it directly to the 3.3V rail on the prototyping board, it seems like its doing now what its programmed to do. Will do further testing to make sure thats the problem is solved.