I have a PIC32MX340F512 board developed by another company for us, The board has a DS1338 RTCC and 24LC32A eeprom, and display unit on an I2C bus, on this bus i included a TSL2561 I2C light sensor, i wrote code in c to poll the light sensor continously , when the light sensor reaches a certain level i save the time and date and light sensor value on SD card. This all works fine but if i leave the system without exposure to light inside tunnel where incident light on one end of the tunnel is ought to be monitored the system becomes unresponsive no matter how much amount of light you apply and then if i switch power off and back on again everything starts to work normal. i am a one man development team and have been trying to find out the problem for months, i activated the watchdog timer to prevent the system from hanging but the problem still persisted. i then decided to find out if the problem is with the sensor by including a push button to activate light measurement but still when 4-5 hours elapse the PIC cant even detect a change in the the input pin. Under the impression that a hardware reset overrides anything going on i included a reset button and it also works ok for the first few hours after that the PIC doesn't seem to be responding to anything including a reset. I was getting convinced that there is nothing wrong with the firmware but also with all this happening the display unit (pic16f1933 and lcd) on the I2C shares power with the main unit and doesn't seem to be affected as it alternates between different messages constantly Does anybody have an idea what could be wrong (hardware/firmware or my sensor). I am using a 24v DC power supply purchased seperately. The PIC seems to go into a deep sleep although i dd not implement any kind of SLEEP mode in my code. Nb We use the same board for many other projects and i haven't come across such a problem . Thanks in advance.
I think you need to (if you haven't already) explore the wonderful world of in-circuit-debugging (such as with the ICD3 or PICkit 2/3). It allows you to run the processor in a special mode that lets you pause execution, see exactly which line of code is being executed, inspect variable values, and step through the code to see which parts are running and not running, or see exactly where execution takes a wrong turn. If the problem takes hours to reproduce, that's okay. You can just leave it overnight running in debug mode and hopefully it will be locked-up or 'sleeping' in the morning. At this point, you will be able to pause the processor and poke around to see if you got caught in some kind of infinite loop or something. This is often the only way to dig inside a running piece of code to see why things aren't working as you expect. But as you say, those bugs that take hours or days to manifest are the trickiest. Good luck!
It sounds like you can break up your design into two main parts, sd card interfacing, reading the rtc and reading the light sensor. If it were me I would upload a version of the code that mimics reading the light sensor but only returns fake data and see if that cures the problem. Additionally do the same with the other two modules separately and see if any of the three versions of your project not show this problem. From there just keep narrowing it down until you find the block of code thats causing problems.
if Two or more versions of your debug code show the same problem then my guess is it has to do with one of the communication protocols. I had a problem with a Pic32 silicon version blocking when using the DMA in conjunction with the SPI peripherals. So I would suggest checking the errata for your chip.
If you still cant find the problem, my only suggestion would be to check for memory leaks or arrays that are growing into reserved memory.
Hope that helps, good luck!
Related
I have been struggling for some time now trying to get my ESP8266 ESP-12 to work. I was able to get it loaded with the NodeMCU software. Now, the board constantly restarts itself. Whether I have a script loaded on it or not, the module seems to continually restart. I am using ESPlorer, and can see it get connection to NodeMCU. Then the board restarts several seconds to several mins later. I have tried various pinout, capacitors, etc. with no luck in solving this problem. I have been searching all over and have had no luck finding a solution. Any help is greatly appreciated. Here is my current pinout:
ESP-12 ----------- TTY 3.3v Serial
================================================
TX ----------------------------- RX
RX ----------------------------- TX
GND, GPIO15 -------------------- GND
VCC, CH_PD, GPIO0, (RST) ------- LD1117v33 voltage regulator +3.3v
GND, GPIO15 -------------------- LD1117v33 voltage regulator GND
Thanks so much in advance for any help!
Assuming the hardware is okay and the right binary is loaded it's almost surly a power problem.
1) Make sure what ever voltage regulator you're using is rated for 200mA or more. In your case the LD1117 can source 800mA so that's good.
2) Make sure you're upstream power supply can source 200mA or more. If you're powering from a USB hub make sure the hub is powered.
3) Make sure you have some large low ESR capacitors across GND and 3.3v. Two capacitors: 10uF and 100uF worked for me (there's nothing magic about these exact values, 10-100uF should work). The ESP8266 can draw huge (relatively) amounts of current for short periods while booting or transmitting. This can cause a bad transient on the power supply, which will cause the system to reboot, which can lead to an infinite reboot cycle.
ESP8266 running lua goes to panic mode if the program loaded on it is has some bug.
Look at your code again. Reflash the firmware and upload code again. Try to upload code bit by bit. So that you know which part is causing the issue.
fix the setup in such way that flashing firmware is super easy. Trust me you will need to reflash it many times if you wanna play with code on it.
I had a NodeMCU dev board which worked fine for some hours, then suddenly restarted and wouldn't stay up. I tried adding power-supply capacitors and using a different power supply, to no avail.
What fixed it for me was resetting the watchdog timer every second:
tmr.alarm(6, 1000, 1, function() tmr.wdclr() end)
The watchdog timer needs to be reset periodically. I don't know how often. My device was resetting after about 35-40 seconds uptime. My code (which ran every 30 seconds from timer) was resetting the watchdog itself. This was not enough, somehow.
Use a pullup resistor on the RST line rather than just connecting it directly to VCC. I used 4.7K, but the actual value is not critical.
Get the serial terminal program named "terminal v1.9b by br#y++". While I wrote this answer I was not able to download. When I find the link I'll add in a comment.
Run the program and set the baud rate to custom and enter the value 74880 or 74400. With this you'll be able to see the fw messages. In this messages there is the reboot reason code. The codes are :
0 -> normal startup by power on
1 -> hardware watch dog reset
2 -> software watch dog reset (From an exception)
3 -> software watch dog reset system_restart (Possibly unfed wd got angry)
4 -> soft restart (Possibly with a restart command)
5 -> wake up from deep-sleep
Looking at the provided code you can decide from what reason the chip is restarting.
If your hardware is good, then the problem should be inside your code.
And sometime your code takes too long to finish, then it will trigger the watchdog to restart.
I suggest that you connect your reset pin to 3.3v via a 10K ohm resistor and to ground via a push button. This way your reset pin is always pulled high to prevent the random resets. I assume that your code has no bugs.
I run a successful Minecraft Tekkit modded server with computer craft on it.
I'm fairly new to lua and only know the basics, I'm trying to make a menu with pages to display the banned items list and rules list on. I've made a program with arrows that's optimized for advanced computers and monitors.
The code runs properly on my advanced computer but doesn't run on the monitor, when it shows and someone clicks the arrows it doesn't work either.
I just started using stack so I'm not sure on what to do, if you need any info please ask for it :)
The code: http://pastebin.com/gVtPeBCE
By the way I already tried using Mon.write and Mon = peripheral.wrap("top")
For those who don't have tekkit here is a computercraft emulator: https://goo.gl/J0dPq0
I'm sorry to inform you that I haven't read through all of your code. But judging based on your description, I would say that it's likely one of three issues, not including incorrect syntax as a possibility.
Note: Your question is exclusively asking about the programs ability to run on a monitor while the emulator you link to only provides the desktop ComputerCraft computers.
Peripheral
Although you already stated:
By the way I already tried using Mon.write and Mon = peripheral.wrap("top")
I would like to clarify that you can, as a way to simplify the code transition, set the peripheral function table equal to the term variable. For example: term = peripheral.wrap(string_side).
Note: When you use this method, you shouldn't execute the program with the command:
> monitor side program.
You should instead run it as a normal program with no special treatment.
I.e. > program.
Incorrect Mouse Event Detection
Simply put, when using a monitor, you're not supposed to pull for a mouse_click event. You have to pull for a monitor_touch event instead.
while true do
type, side, x, y = os.pullEvent()
if type == "monitor_touch" then
print("Monitor '"..side.."' has been pressed at "..x..", "..y.."!")
end
end
Monitor Size
This just simply means that the program you're trying to execute on the monitor takes up to much space and is therefore unusable when displayed on that size of monitor.
Suggestion: Either update your code for the monitor size or build the monitor to fit the program.
Please remember that all of these ideas might not answer your question, as the code you have provided to look over is too large and I haven't been able to find the time to experiment with it. Therefore, these are only general suggestions.
if i had to guess, it's because term is short for terminal and will auto work with computers so if you set term to be the monitor at the top of the file it should work correctly.
term = peripheral.wrap("SIDE OF MONITOR")
Put that at the top of your code and it should work. but this what i think it is after taking a look at your code (also its not that long of a code sample...)
I have been using Vivado Logic Analyzer for months. and believe me it took so much time to properly see the debug singals on waveform. I usually mark the debug signals on block design and then synthesize and generate bitstream . But sometimes i can see my clock on debug "FCLK" or sometimes "ProcessingSystemFCLK, using (Setup_debug on synthesized designs ) . Then also sometimes i can see proper transiitons of waveform on ILA , and sometimes i can see only one straight value there; No transiitons whatsoever. Sometimes I get LUTRAM error and sometimes the bit stream generated successfully.
It will be appreciated if one can tell me the proper sequence for debugging signals and whether first to program device using Vivado or using SDK. And also kindly clarify above points too.
thanks so much
Regards
There are many bugs lurking in the Vivado ILA code, I've run into many myself. I have had the most success generating the ILA in a managed IP project and manually instantiating it in the RTL (use the example project to get a template). That way you can be sure what clock it is running on. If you are getting different clocks I would guess this is why your probes seem to behave differently.
If your device is getting full, Vivado can sometimes fail routing with large ILA blocks. If you rerun the build you may get different results.
As far as programming it, it doesn't matter if it is programmed with Vivado or SDK, but Hardware Manager only exists in Vivado, so you'll need to bring this up and point to the .ltx file to view the probes (don't forget to refresh the device).
I am attempting to stream audio files from a server to iOS devices and play them completely synchronized. For example on my phone I might be 20 secs into a song and then my friend next to me should also be 20 secs into the song as well. I know this is not an easy problem to solve, but I am attempting to do so.
I can currently get them within one second of each other by calculating the difference in time between the devices and then have them sync up, however that is not good enough because the human ear can detect a major difference in a second and this is over WIFI.
My next approach is going to be to unicast the one file from the server and then have the all devices pick it up directly from the server and then implement some type of buffer system similar to netflix so that network connectivity would be a limiting factor. http://www.wowza.com/ is what I would use to help with that.
I know this can be done, because http://lysn.in/ is does it with their app and I want to be able to do something similar.
Any other recommendations after I try my unicast option?
Would implementing firebase help solve a lot of the heavy lifting problems?
(1) In answer to ONE of your questions (the final one):
Firebase is not "realtime" in "that sense" -- PubNub is probably (almost certainly) the fastest "realtime" messaging for and between apps/browser/etc.
But they don't mean real-time in the sense of real-time, say, as race game engineers mean it or indeed in your use-case.
So firebase is not relevant to you here and won't help.
(2) Regarding your second general question: "how to synchronise time on two or more devices, given that we have communications delays."
Now, this is a really well-travelled problem in computer science.
It would be pointless outlining it here, because it is fully explained here http://www.ntp.org/ntpfaq/NTP-s-algo.htm if you click on "How is time synchronised"?
So in fact, to get a good time base on both machines, you should use that! Have both machines really accurately set a time to NTP using the existing (perfected for decades) NTP synchronisation.
(So for example https://stackoverflow.com/a/6744978/294884 )
In fact are you doing this?
It's possible that doing that will solve all your problems; then just agree to start at a certain exact time.
Hope it helps!
I would recommend against using the data movement to synchronize the playback. This should be straightforward to do with a buffer and a periodic "sync" signal that is sent at a period of < 1/2 the buffer size. Worst case this should generate a small blip on devices that get ahead or behind relative to the sync signal.
This has happened to me on more than one occasion and has led to many lost hours chasing a ghost. As typical, when I am debugging some really difficult timing-related code I start adding tons of OutputDebugString() calls, so I can get a good picture of the sequence of related operations. The problem is, the Delphi 6 IDE seems to be able to only handle that situation for so long. I'll use a concrete example I just went through to avoid generalities (as much as possible).
I spent several days debugging my inter-thread semaphore locking code along with my DirectShow timestamp calculation code that was causing some deeply frustrating problems. After having eliminated every bug I could think of, I still was having a problem with Skype, which my application sends audio to.
After about 10 seconds the delay between my talking and hearing my voice come out of Skype on the second PC that I was using for testing, the far end of the call, started to grow. At around 20 - 30 seconds the delay started to grow exponentially and at that point triggered code I have that checks to see if a critical section was being held too long.
Fortunately it wasn't too late at night and having been through this before, I decided to stop relentlessly tracing and turned off the majority of the OutputDebugString(). Thankfully I had most of them wrapped in a conditional compiler define so it was easy to do. The instant I did this the problems went away, and it turned out my code was working fine.
So it looks like the Delphi 6 IDE starts to really bog down when the amount of OutputDebugstring() traffic is above some threshold. Perhaps it's just the task of adding strings to the Event Log debugger pane, which holds all the OutputDebugString() reports. I don't know, but I have seen similar problems in my applications when a TMemo or similar control starts to contain too many strings.
What have those of you out there done to prevent this? Is there a way of clearing the Event Log via some method call or at least a way of limiting its size? Also, what techniques do you use via conditional defines, IDE plug-ins, or whatever, to cope with this situation?
A similar problem happened to me before with Delphi 2007. Disable event viewing in the IDE and instead use DebugView from Sysinternals.
I hardly ever use OutputDebugString. I find it hard to analyze the output in the IDE and it takes extra effort to keep several sets of multiple runs.
I really prefer a good logging component suite (CodeSite, SmartInspect) and usually log to various files. Standard files for example are "General", "Debug" (standard debug info that I want to collect from a client installation as well), "Configuration", "Services", "Clients". These are all set up to "overflow" to a set of numbered files, which allows you to keep the logs of several runs by simply allowing more numbered files. Comparing log info from different runs becomes a whole lot easier that way.
In the situation you describe I would add debug statements that log to a separate logfile. For example "Trace". The code to make "Trace" available is between conditional defines. That makes turning it on pretty simple.
To avoid leaving in these extra debug statements, I tend to make the changes to turn on the "Trace" log without checking it out from source control. That way, the compiler of the build server will throw out "identifier not defined" errors on any statements unintentionally left in. If I want to keep these extra statements I either change them to go to the "Debug" log, or put them between conditional defines.
The first thing I would do is make certain that the problem is what you think it is. It has been a long time since I've used Delphi, so I'm not sure about the IDE limitations, but I'm a bit skeptical that the event log will start bogging down exponentially over time with the same number of debug strings being written in a period of 20-30 seconds. It seems more likely that the number of debug strings being written is increasing over time for some reason, which could indicate a bug in your application control flow that is just not as obvious with the logging disabled.
To be sure I would try writing a simple application that just runs in a loop writing out debug strings in chunks of 100 or so, and start recording the time it takes for each chunk, and see if the time starts to increase as significantly over a 20-30 second timespan.
If you do verify that this is the problem - or even if it's not - then I would recommend using some type of logging library instead. OutputDebugString really loses it's effectiveness when you use it for massive log dumps like that. Even if you do find a way to reset or limit the output window, you'd be losing all of that logging data.
IDE Fix Pack has an optimisation to improve performance of OutputDebugString
The IDE’s Debug Log View also got an optimization. The debugger now
updates the Log View only when the IDE is idle. This allows the IDE to
stay responsive when hundreds of OutputDebugString messages or other
debug messages are written to the Debug Log View.
Note that this only runs on Delphi 2007 and above.