Can only start 5 cogs?

Comments

• Duane Degn Posts: 10,588

  2015-01-25 17:18 edited 2015-01-25 17:18

  I don't know if it's the source of your trouble but you're calling the xb object from multiple cogs. This can cause problems.
• eagletalontim Posts: 1,399

  2015-01-25 17:20 edited 2015-01-25 17:20

  Just noticed that, but it did not fix the problem
• Duane Degn Posts: 10,588

  2015-01-25 17:51 edited 2015-01-25 17:51

  If you attached your code as an archive, it would be easier for others to test it out.
• Peter Jakacki Posts: 10,193

  2015-01-25 18:01 edited 2015-01-25 18:01

  I count 6 cogs that I can directly see in your code but as Duane mentioned you should archive the project so we can see all the references etc.
  
  COGS
  0 spin
  1 pst
  2 adc
  3 controlMovement
  4 Handle_Wifi
  5 xb
  6 ?
  7 ?
  
  As we can see in the code posted that Handle_WiFi also starts the xb cog as well. I don't know about pst and adc if they do anything extra.
• eagletalontim Posts: 1,399

  2015-01-25 19:03 edited 2015-01-25 19:03

  Ok, here they are zipped up Hope this helps.
  
  Edit. It is modified a bit from the original posted as I keep trying different things to make it work. Still no luck yet

  zip

  zip

  Solar Tracker V1.zip

  10K

  Solar Tracker V1.zip 9.9K
• Peter Jakacki Posts: 10,193

  2015-01-25 19:20 edited 2015-01-25 19:20

  eagletalontim wrote: »

  Ok, here they are zipped up Hope this helps.
  
  Edit. It is modified a bit from the original posted as I keep trying different things to make it work. Still no luck yet

  
  That didn't include "Parallax Serial Terminal" but if you use the "archive" function in the File menu it will include all files.
• Duane Degn Posts: 10,588

  2015-01-25 19:41 edited 2015-01-25 19:41

  Nothing jumps out at me. I don't like to see coginit calls. IMO, they invite trouble.
  
  Since the original code didn't include coginit calls I'm guessing you added them out of desperation.
  
  What are you expecting the code to do which it's not doing?
  
  I noticed your buffer index in "Handle_Wifi" is not checked to make sure it doesn't overflow the buffer. It's not uncommon for FDS to pick up $FF values from an idle line. There's chance your buffer is overflowing though I kind of doubt this.
  
  I don't think you're running out of cogs. I think your problem is elsewhere (where it is I don't know).
• eagletalontim Posts: 1,399

  2015-01-25 19:47 edited 2015-01-25 19:47

  Hmm, I thought the Prop tool came with the PST. Let me try it again.
  
  EDIT * : The weird thing is, I can null out any of the lines that start a new cog and the program will run....just without that feature.

  zip

  zip

  suntracker - Archive.zip

  21K

  suntracker - Archive.zip 20.5K
• Peter Jakacki Posts: 10,193

  2015-01-25 20:12 edited 2015-01-25 20:12

  I still only count 6 cogs in action as mentioned before. What are you trying to do that won't work? Perhaps it is a conflict of resources rather than "can only start 5 cogs".
  
  Why do you coginit instead of cognew? Are you saying that this program as is won't work unless you disable one of the cog start lines? Example?
  
  
  EDIT: you are taking chances hoping that the "buffer" does not overflow which could easily happen with transmission errors and noise etc. Always put a limit on your buffer writes, easy to just make this buffer 256 bytes and limit the write index to a single byte.
  
  
  But what is going on here!!!!!! 400 longs ---- wahhhh!!!
  LONG variableStack[400]
  LONG moveStack[400]
  LONG wifiStack[400]
• eagletalontim Posts: 1,399

  2015-01-25 20:16 edited 2015-01-25 20:16

  The program hangs at the beginning where all the cogs are started unless I null out one of them....any one of them. If I null out only the ADC cog start, the program will continue processing but I will have no ADC displayed in the terminal. If I null out only the controlMovement cog start, the program will continue. Same goes with the XB (Full Duplex Serial) line.
  
  If you run the code and open the serial terminal, you will see what is happening
• Peter Jakacki Posts: 10,193

  2015-01-25 20:34 edited 2015-01-25 20:34

  eagletalontim wrote: »

  The program hangs at the beginning where all the cogs are started unless I null out one of them....any one of them. If I null out only the ADC cog start, the program will continue processing but I will have no ADC displayed in the terminal. If I null out only the controlMovement cog start, the program will continue. Same goes with the XB (Full Duplex Serial) line.
  
  If you run the code and open the serial terminal, you will see what is happening

  
  It's working fine with all cogs as far as I can tell. The only thing I did extra was insert a 3 second startup delay so I could switch to the terminal. As each cog starts up it draws a little more current but unless your hardware was really underpowered I can't see that being a problem. But if it is not adequately decoupled then that is probably your problem.
• eagletalontim Posts: 1,399

  2015-01-25 20:36 edited 2015-01-25 20:36

  Peter Jakacki wrote: »

  I still only count 6 cogs in action as mentioned before. What are you trying to do that won't work? Perhaps it is a conflict of resources rather than "can only start 5 cogs".
  
  Why do you coginit instead of cognew? Are you saying that this program as is won't work unless you disable one of the cog start lines? Example?
  
  
  EDIT: you are taking chances hoping that the "buffer" does not overflow which could easily happen with transmission errors and noise etc. Always put a limit on your buffer writes, easy to just make this buffer 256 bytes and limit the write index to a single byte.
  
  
  But what is going on here!!!!!! 400 longs ---- wahhhh!!!
  LONG variableStack[400]
  LONG moveStack[400]
  LONG wifiStack[400]

  
  I tried coginit out of desperation to get this working. Did not help.
  
  Yes, if I disable any cog start, the program will run.
  
  I never did understand the Stack part of a cog and I usually put 100 or 200. I tried 400 out of desperation as well....
• Peter Jakacki Posts: 10,193

  2015-01-25 20:45 edited 2015-01-25 20:45

  eagletalontim wrote: »

  I tried coginit out of desperation to get this working. Did not help.
  
  Yes, if I disable any cog start, the program will run.
  
  I never did understand the Stack part of a cog and I usually put 100 or 200. I tried 400 out of desperation as well....

  
  100 is already way over the top but your problem seems to be hardware decoupling.
• eagletalontim Posts: 1,399

  2015-01-25 20:46 edited 2015-01-25 20:46

  Hmm. I just loaded the program on my breadboard Prop and it seems to be working? So now I am down to decoupling?
  
  Here is the last screen shot of my circuit board layout before I ordered them.
  
  Is there something that was missed? Should I use a different value decoupling cap on the Prop pins?

  

  

  SUN-TRACKER-4.jpg

  780 x 488 - 363K

  SUN-TRACKER-4.jpg 363.2K
• Peter Jakacki Posts: 10,193

  2015-01-25 21:04 edited 2015-01-25 21:04

  eagletalontim wrote: »

  Hmm. I just loaded the program on my breadboard Prop and it seems to be working? So now I am down to decoupling?
  
  Here is the last screen shot of my circuit board layout before I ordered them : http://forums.parallax.com/showthread.php/158583-PCB-Design-help-for-powering-Prop-controlling-12V-motors?p=1309367&viewfull=1#post1309367
  
  Is there something that was missed? Should I use a different value decoupling cap on the Prop pins?

  
  The two caps look ok where they are but just check they are intact (or wrong value) but just to make sure just tack a known through-hole 0.1uf across 9 and 12 directly. Unplug your XBee as that may be drawing a bit of current on start-up and the Prop could have benefited from either its own regulator or at least a direct track back to the main regulator (not via a potential noise source). If your XBee is a 100mW version it could draw quite a bit of current which the regulator should handle but obviously something is happening, so unplug it and check.
• eagletalontim Posts: 1,399

  2015-01-25 21:06 edited 2015-01-25 21:06

  I changed it before that last screen shot I posted in the link. Post above is edited with correct screen shot.
  
  Edit * : I have also unplugged the Xbee and tried to run it, but no luck
• Peter Jakacki Posts: 10,193

  2015-01-25 21:27 edited 2015-01-25 21:27

  eagletalontim wrote: »

  I changed it before that last screen shot I posted in the link. Post above is edited with correct screen shot.

  
  That's better. You know that regulators don't have to stay in "the power supply area", they work even better when you place them close to the load. Just a tip.
  
  But make no assumptions here, solder a known 0.1uF cap directly to the Prop socket and also measure the supply voltages because if your 5V supply drops then this may affect your 3.3V supplies depending upon what type of regulators you are using there. If you put an LED on the EEPROM SCL line to 3.3V through a 1K resistor you will be able to see it light up when the Prop boots, or in this case, if it reboots because of a supply glitch.
• eagletalontim Posts: 1,399

  2015-01-25 21:39 edited 2015-01-25 21:39

  I will try to connect my O-Scope to this tomorrow when I get home from work. It is late here and I need to get some sleep before I don't wake up for work. Should I stack a known 0.1uF cap on the existing ones or solder to the socket pins on the back side of the board?
  
  I supposed do this to both decoupling caps?
• Peter Jakacki Posts: 10,193

  2015-01-25 21:59 edited 2015-01-25 21:59

  eagletalontim wrote: »

  I will try to connect my O-Scope to this tomorrow when I get home from work. It is late here and I need to get some sleep before I don't wake up for work. Should I stack a known 0.1uF cap on the existing ones or solder to the socket pins on the back side of the board?
  
  I supposed do this to both decoupling caps?

  
  To be safe for this test solder it direct to the socket pins with a cap that you know for sure is 0.1uF or thereabouts. SMD caps can get mixed up and you can't easily tell what it is in that case. For this test you really only need one but if it's easy enough to do two, then do two. If the problem still persists then try the scope but not before you put a simple diagnostic LED on the board as I mentioned. You just want to know when it reboots.
• ozpropdev Posts: 2,793

  2015-01-25 22:46 edited 2015-01-25 22:46

  Just to confirm, I just fired up your code on my BeMicro CV board running the Propeller 1 Verilog image.
  The code seems to be running Ok and the COG leds indicate 6 x cogs running.
  I agree with Peter that decoupling seems to be the gremlin.
• eagletalontim Posts: 1,399

  2015-01-26 18:11 edited 2015-01-26 18:11

  Ok....back at it again. I have found that the lockup does not happen right away. Some how, I think the prop was able to stay powered long enough to retain memory while this was happening even with the battery disconnected? I tested the voltage between logic ground and the 3.3V rail for the prop with the Prop Plug plugged in and it was 2.46V. When I remove it, the voltage goes down to 0.96 and hangs there for awhile till it slowly dwindles out.
  
  I went ahead and soldered on 2 known 0.1uF caps directly to the socket pins and noticed no difference on the O-Scope. The line is pretty flat honestly.
  
  So... having checked all this, I feel as though I something else may be the issue. Right now, the code seems to be running just fine with all cogs fired up.
  
  To better understand about overflowing a variable, is there any "simple" explanation of how to prevent this? Do I just set BYTE index[200] and be done with it?
• Peter Jakacki Posts: 10,193

  2015-01-26 18:28 edited 2015-01-26 18:28

  eagletalontim wrote: »

  Ok....back at it again. I have found that the lockup does not happen right away. Some how, I think the prop was able to stay powered long enough to retain memory while this was happening even with the battery disconnected? I tested the voltage between logic ground and the 3.3V rail for the prop with the Prop Plug plugged in and it was 2.46V. When I remove it, the voltage goes down to 0.96 and hangs there for awhile till it slowly dwindles out.
  
  I went ahead and soldered on 2 known 0.1uF caps directly to the socket pins and noticed no difference on the O-Scope. The line is pretty flat honestly.
  
  So... having checked all this, I feel as though I something else may be the issue. Right now, the code seems to be running just fine with all cogs fired up.
  
  To better understand about overflowing a variable, is there any "simple" explanation of how to prevent this? Do I just set BYTE index[200] and be done with it?

  
  If you allow for a bleed resistor across your 3.3V supply then this will help with regulation by maintaining a minimum current, and also help with discharging supply capacitance as well as "load up" leakage currents that result from external devices such as USB feeding current through I/O pins back into the supply. Try a value of 1K.
  
  Depending upon what you are using there I doubt very much that the "O-Scope" will pick up glitches, they only have to be tens of nanoseconds long. I know that the Tektronix scopes have a "peak detect" mode to make sure you see where those glitches are.
  
  As for writing to array variables I would always put in index limiting, either in the form of ANDing a mask, or modulus. The other way that I have already mentioned to you is to just declare a byte variable for the index and create a 256 element buffer, that way there is no need to mask as even if you progress past 255 it will just wrap to 0 etc.
• eagletalontim Posts: 1,399

  2015-01-26 18:35 edited 2015-01-26 18:35

  Ok, so basically an IF statement.
  

  BYTE index
  .......
  
  repeat
    index++
    if index == 256
     index := 0
    ' do something with index variable
  

  
  I know there is a shorter way to write that, just can't seem to remember how :P I know I have seen it before.
  
  EDIT : This is the O-scope I have : http://www.ebay.com/itm/Mini-Digital-Storage-Color-Oscilloscope-Metal-Handheld-scope-DSO-203-Nano-Black-/221079075360
• Sapphire Posts: 497

  2015-01-26 18:51 edited 2015-01-26 18:51

  You don't need
  

    if index == 256
     index := 0
  

  
  because if index is 255 when you do index++ it will become zero. A byte cannot exceed 255, and 255 + 1 = 0.
  
  In fact,

    if index == 256
  

  will never be true.
• Peter Jakacki Posts: 10,193

  2015-01-26 18:53 edited 2015-01-26 18:53

  eagletalontim wrote: »

  Ok, so basically an IF statement.
  

  BYTE index
  .......
  
  repeat
    index++
    if index == 256
     index := 0
    ' do something with index variable
  

  
  I know there is a shorter way to write that, just can't seem to remember how :P I know I have seen it before.
  
  EDIT : This is the O-scope I have : http://www.ebay.com/itm/Mini-Digital-Storage-Color-Oscilloscope-Metal-Handheld-scope-DSO-203-Nano-Black-/221079075360

  
  The whole idea of declaring index as a byte is so that it can never exceed 255 so there is no need to test and reset which btw would normally test for anything in excess of 255 rather than equality (just in case). But remember to allocate 256 elements for your buffer then. I don't think you can declare a local variable as a byte in Spin but just make it a global variable (maybe rename it) like this:
  BYTE index,buffer[256]
  
  
  That scope is just a baby scope so don't expect any wonders from it, handy as it is, it just doesn't have the performance and features of a digital bench scope, so it is not likely that it will show or even trigger on those little glitches. One good thing about them though, as you said "The line is pretty flat honestly" so the display is nice n smooth
• eagletalontim Posts: 1,399

  2015-01-26 18:56 edited 2015-01-26 18:56

  Ok, that makes sense. It appears as though this issue has been resolved and now I am on to trying to fix another... Not sure if I should start a new thread or keep trying to figure it out on my own.
• Peter Jakacki Posts: 10,193

  2015-01-26 18:58 edited 2015-01-26 18:58

  eagletalontim wrote: »

  Ok, that makes sense. It appears as though this issue has been resolved and now I am on to trying to fix another... Not sure if I should start a new thread or keep trying to figure it out on my own.

  
  Just start a new thread and tell us what you do know, what we should know, and what you don't know. That way those of us in the know will be able to let you know, if you know what I mean, no?
• eagletalontim Posts: 1,399

  2015-01-26 19:00 edited 2015-01-26 19:00

  Lol, well put
• eagletalontim Posts: 1,399

  2015-01-26 19:43 edited 2015-01-26 19:43

  Ok....I thought I had this figured out but one thing I forgot to do was test all the functions.... The PST is working and I can see what is going on now, but apparently the ADC does not actually start. It shows 0's across the board....unless I null out one of the other cogs then it starts working. This is getting frustrating!
  
  What I am thinking is going on is I am possibly "over running" a variable somewhere in my "PUB go". Problem is...I don't know how to find which one unless I start nulling out lines.
  
  Blah.....
  
  EDIT *** :I have nulled out pretty much the entire PUB go and it is still not working. The Prop is not resetting and the PST is still updating properly as I can see when "East switch" is on or off.

  zip

  zip

  suntracker - Archive.zip

  27K

  suntracker - Archive.zip 27.3K
• eagletalontim Posts: 1,399

  2015-01-26 20:04 edited 2015-01-26 20:04

  After a bit more trial and error, I have found that if I null out everything in the controlMovement section, it works... If I un null the repeat, the ADC dies.... Any more ideas on what would cause this?