Shop OBEX P1 Docs P2 Docs Learn Events
Memory Loss? Brownout detector required? — Parallax Forums

Memory Loss? Brownout detector required?

JomsJoms Posts: 279
edited 2010-03-13 15:43 in Propeller 1
I am in the process of building a few prototype boards onto a printed circuit board I had made.· The problem is that I can load the EEPROM and the unit works fine, until I remove power and re-apply.· Then it does random things such as one cog not starting.· To correct this I reload the EEPROM or even re-load the RAM and it will correct the problem until the next power cycle.

I attached a quick copy of my layout, but pulling my hair out as to why this is happening...· I have four seperate boards put together now and they are all doing the same thing....··· Does anyone have any ideas on what could cause this?·· Do I need to add some type of a brown-out detector like on the BS2?

Thanks in advance for any ideas...
pdf
pdf
Forum.pdf
43K
«1

Comments

  • Erik FriesenErik Friesen Posts: 1,071
    edited 2010-03-06 22:27
    Are you using serial? If so it could be cycling your reset pin through ftdi.
  • JomsJoms Posts: 279
    edited 2010-03-06 22:39
    Im using usb thru the FT232RL R chip. The circuit I am making is a four channel video unit. It will make 4 channels of analog video to display different text on four different monitors. When I mean one cog isn't starting, on one board monitors 1,3,4 work, then on the second board monitors 1,2,3 work.

    But the weird part is that the Prop will work fine to the working channels, but until I do a reload of the RAM, all don't work. I am assuming it can't be an EEPROM problem because it shows verifying and does not bring up any errors.

    If it was reseting the Prop, wouldn't they all not work?
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2010-03-06 23:02
    Your pullup is going to SCL when it really needs to go to SDA, that is, if your diagram is correct. The 220R resistors are redundant.

    Forget it, I keep looking at the bottom device as the EEPROM, too much of a rush, have to go.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*

    Post Edited (Peter Jakacki) : 3/6/2010 11:08:44 PM GMT
  • JomsJoms Posts: 279
    edited 2010-03-07 04:45
    OK, I still don't think I'm understanding this part at all...

    I read the Prop Manual and it appears that even though I press F11 to load the EEPROM, it still loads the RAM off the computer. So, what is happening, is that if I load the RAM off the computer it works great, if I load it off of the EEPROM (after power fail), it has different problems.

    I highly dought I have several bad EEPROM's? If the spin software verifies after writing and no error, doesn't that mean its wired properly?

    Any ideas would be extreamly helpful on this one....
  • Mike GreenMike Green Posts: 23,101
    edited 2010-03-07 05:15
    The boot routine in the Propeller's ROM always loads the program into RAM. If the Propeller Tool tells it to copy it to EEPROM the boot routine does so after the program is loaded into RAM. There's a different part of the boot routine that loads the program from EEPROM into RAM.

    I don't see anything obvious in your schematic. Make sure all Vdd and Vss pins are connected
  • potatoheadpotatohead Posts: 10,261
    edited 2010-03-07 05:22
    Have you tried programming for one cog, then two, then three, etc... each time starting from EEPROM?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Safety Tip: Life is as good as YOU think it is!
  • JomsJoms Posts: 279
    edited 2010-03-07 05:54
    Mike: That explination sounds like it would explain some of what is happening. Because of how you explained it, I would have to lean towards a problem with the EEPROM then. I am using the 32KB (24LC256), but perhaps I am having a memory over-run? My program is taking up 1240 Longs and the Variables are taking up 6327 Longs.

    Am I correct in this statement?
    1240 / 8 = 15.500 KB (32KB EEPROM so about half used?)

    I have double and triple checked all the grounds, +3.3v, pull-up resistor and data connections. I have also used a meter to make sure it isn't a joint.

    Potatohead: I have also tried this. I should only be using 5 cogs, but the problem is as I start with one and keep working up, it will appear to work until I start getting to the upper numbers. I am starting to think it is a memory over run because of this.

    Also, if I load the entire program, it will only act up for the first few minutes, then it will straighten out on its own and start working again. I know, sounds almost impossible, but it does. Would this be after the variables re-write themselves a few times?

    Ideas on how to check for a memory over-run?
  • potatoheadpotatohead Posts: 10,261
    edited 2010-03-07 06:04
    Have all the cogs display the same buffer.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Safety Tip: Life is as good as YOU think it is!
  • JomsJoms Posts: 279
    edited 2010-03-07 06:07
    Do what? Sorry, don't understand that exactly...

    Basically my cogs go as follows...

    Cog0 - General Program
    Cog1 - Serial Control
    Cog2 - Video 1 Out
    Cog3 - Video 2 Out
    Cog4 - Video 3 Out
    Cog5 - Video 4 Out
    Cog6 - WatchDog (resets device if unit locks up)
    Cog7 -

    I let the cogs open under whatever address they want as I'm using the same object for cogs 2,3,4,5.

    EDIT -·Would this problem cause it to act random for the first few minutes its power up, then work fine after that?·· Basically by weird, I mean that 1 or 2 of the video channels will not work, but it is not consistant from trial to trial...
  • Mike GreenMike Green Posts: 23,101
    edited 2010-03-07 06:12
    You may well have too much you're trying to fit into memory (RAM). Remember that 1240 longs of program plus 6327 longs of data is 7567 longs which is just a little less than 32K bytes. What's probably happening is that you've forgotten that there needs to be room for the stack as well (that stack / free area!). You've left only 625 longs for the main stack space. That may be enough. It depends on how much you need for nested method calls and local variables.

    How about attaching the source program of your program to a followup message? Do NOT cut and paste your code into a message. Use the Post Reply button instead of the Quick Reply box and you'll see a button for the Attachment Manager which is what you should use.
  • potatoheadpotatohead Posts: 10,261
    edited 2010-03-07 06:15
    What I was getting at was buffer space for the displays. It does not take all that much to fill the HUB. Use the same screen buffer for all the display cogs, so they are all displaying the same thing. If that works, your circuit, cog startup, and core stack requirements are probably vetted.

    That leaves active display buffer memory to contend with. If everything ends up running in COGs, after init, you could use the whole HUB memory for display, so long as there is no SPIN operating at that time. If there is SPIN operating, overwriting memory is more difficult, because that needs to exist in the HUB, along with it's variable storage, stack, etc...

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Safety Tip: Life is as good as YOU think it is!
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-03-07 06:32
    Joms,

    How are your starting your cogs? Are you using coginit or cognew?

    -Phil
  • JomsJoms Posts: 279
    edited 2010-03-07 06:36
    OK, I attached my entire code with the objects.· The objects are from Parallax and I am using the video overlay one from Terry @ Hitt.

    Potatohead - I think that would work, except I want to be able to have different text on the four screens.· I am actually using this with a LM1881 (four of them) chips to allow video overlay.

    Basically the circuit works great, except when I load from the EEPROM it takes 1 or two of the displays up to 3-4 minutes to come on.

    I recently added the watchdog also incase the program gets hung up in the serial receive part, it will reboot automatically.· I did try to comment this out, but has no effect on this problem....
    zip
    zip
    4Ch_VideoControl - Archive [Date 2010.03.07 Time 00.33].zip
    18K
  • JomsJoms Posts: 279
    edited 2010-03-07 06:38
    PhiPi - I am using cognew, but I did look at coginit also. It was my understanding from the manual that cognew will start in the next available cog, but coginit needs to be directed to a specific cog to open within. Is that correct?
  • potatoheadpotatohead Posts: 10,261
    edited 2010-03-07 06:43
    Joms, I know you want a different display, but you are also having trouble starting up all the displays. The idea behind one buffer is to factor out some variables to confirm others. Once all displays can consistently start up with the shared buffer, you then only have to deal with the buffer, and where it is, the size it is, when it's initalized, etc...

    On the other hand, if you've other issues, like the coginit, vs cognew, and buffers, you are working in a case where there are multiple unknowns, which is difficult to sort out. That's all I was getting at. I find with video things, controlling as much of the environment as possible is a good thing. Having established a solid foundation, then build things out, one by one, limiting changes to facilitate debugging and to not introduce new unknowns or variables along the way, means measured steps one can tackle more easily.

    If the common buffer does not change things, you've narrowed the scope of your search considerably, which is a good thing too.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Safety Tip: Life is as good as YOU think it is!

    Post Edited (potatohead) : 3/7/2010 6:49:20 AM GMT
  • JomsJoms Posts: 279
    edited 2010-03-07 06:50
    OK, I understand. I attempt to do that often also, but this project kind of got out of hand on me. When I was building it on the breadboard I only ever checking 1 channel at a time because I was only ever using one LM1881 ic. However, now that I have all four hooked up I found this problem.

    What would be the easiest way to have all overlays look at one buffer? Because I am only really using two lines of text that are 18 charactors long, could I decrease the size? I did try to decrease the size, but when I move the text to a different position on the screen, it does not work properly.

    Basically, when dealing with the variables, I don't think I am changing the right numbers causing more harm then good...
  • potatoheadpotatohead Posts: 10,261
    edited 2010-03-07 06:57
    A quick look at the overlay shows it requires 6K of RAM for it's 256x192 pixel monochrome display buffer. 4 of these is 24K!!

    Each one also includes some 8x8 font data, that's 1K or so, that's shared by virtue of how SPIN works.

    Each instance of the overlay calls out the @screen variable to reserve it's buffer space. Do that in the parent spin program, passing the address, the same address, to all four instances, or hard code it.

    Just comment out where the overlay defines it's screen and plop an address in there instead.

    I think your screen requirements can be met, but perhaps after things are running, and only at tested safe addresses, where things maybe overwritten after they are safely running on a COG.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Safety Tip: Life is as good as YOU think it is!

    Post Edited (potatohead) : 3/7/2010 7:04:16 AM GMT
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-03-07 07:05
    Joms,

    Using cognew is the right approach.

    -Phil
  • heaterheater Posts: 3,370
    edited 2010-03-07 09:02
    As people get older memory loss can become a serious problem, for others a brownout detector would be a very good idea[noparse]:)[/noparse]

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2010-03-07 09:42
    Coming back to your circuit there is no reason to have the RTC and EEPROM on separate lines as I2C is a bus. I have used the 1307 on the same bus but this is my circuit configuration below. There is no need for current limit resistors as the RTC does not source current, only sinks as per I2C specifications. Also the Vih of the 1307 is a minimum of 2.2V at VCC=5.0V so there is no problem interfacing to the Propellers 3.3V pullups. Pin 3 on the RTC is Vbat (ignore my label) and needs to be at a lower level than VCC to operate normally and since I use a supercap rather than a battery I simply ensure that the battery is charged to about 3.4V using the 1.6V drop of the red LED.

    The pullup on SCL is not really required in most circumstances and these Propeller circuits may never require them but they are good practice and part of the I2C specification.

    Of course you are free to do as you like with your circuit but this is a little "design note" for others then who may simply copy your circuit.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    *Peter*
    rtc+eeprom.png
    960 x 514 - 31K
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-03-07 11:32
    Simplistic thoughts ...

    The code isn't spiking the boot EEPROM. That would let it load from Proptool, verify and load into the HUB ram, but not on repowering.

    Edit

    Just thought does it load back in the first place, the verify could only check it against the ram version, so the only bit that runs ok is the original ram loading from the Proptool, so there must be an over write happening. What if the WP pin on the EEPROM is raised before power is removed, and then repowering?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point

    Post Edited (Toby Seckshund) : 3/7/2010 11:46:46 AM GMT
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-03-07 11:49
    Heater

    RE Your thoughts on brownout detectors, We come into this world and sociaty finds it is acceptable for nappies to be filled. We leave this world and sociaty accepts that nappies may be filled. It is only in the middle part of our lives that the facist state system robs us of the free choice.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • heaterheater Posts: 3,370
    edited 2010-03-07 12:12
    Toby, I thought long and hard before posting that particularly tasteless comment. In the end I could not resist. My apologies to all concerned. Seems that it's a deeper question than I thought.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    For me, the past is not over yet.
  • potatoheadpotatohead Posts: 10,261
    edited 2010-03-07 16:46
    I found it entertaining.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Safety Tip: Life is as good as YOU think it is!
  • JomsJoms Posts: 279
    edited 2010-03-07 19:47
    heater: Actually, you may be on to something here... I have found that my memory is not working very well, and may be perhaps leading to this problem.... Thats why I just gave it up last night and headed for bed [noparse];)[/noparse] (Always good to have humor in everyday problems!)

    Toby: I understand the concern on the WP pin, but not quite sure how this could happen as they are using the same ground and +3.3. This is my first time using USB thru my own circuit and not relying on the Prop Plug. Could there be something I am missing here so that when I am plugging the USB in/out it causes adverse effects? Is it extreamly important to stop (safely remove hardware) before unplugging?

    What do you mean when you say it isn't spiking the EEPROM? The code does load into RAM properlly from the PropTool, and appears to load properly to the EEPROM, however it does not work when power cycled. I have never had the unit not work when loading the RAM from the prop tool, however it only works about %25 percent of the time when loaded from the EEPROM. (hopefully that is clear as mud)

    Peter: Thank you a TON for that info. I will keep these things in mind and actually when I get this problem solved, Im going to try and start moving them to one buss.

    Potatohead: I attempted your idea of looking at one peice in the ram. I believe I am doing it correctly because when I go to object info it shows the RAM used is a lot less. However, I am still haveing the problem. Would that point to hardware then?

    Everyone: THANK YOU a ton in helping with this problem, and for the humor, we need that to keep coming [noparse];)[/noparse]
  • potatoheadpotatohead Posts: 10,261
    edited 2010-03-07 20:08
    When you run it from the prop tool, do all the displays work, and display the same thing?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Propeller Wiki: Share the coolness!
    8x8 color 80 Column NTSC Text Object
    Safety Tip: Life is as good as YOU think it is!
  • JomsJoms Posts: 279
    edited 2010-03-07 20:10
    Yes, All displays work when ran from the Prop Tool, but not from the EEPROM. Same thing it does when I am running all four seperatly
  • Toby SeckshundToby Seckshund Posts: 2,027
    edited 2010-03-07 20:14
    In a meandering way I was tinking that some how you are writing to the boot EEPROM and corupting it, but as you have the RTC on separate pins that shouldn't happen without the code having things wrong. The WP pin is tied to ground, as standard on most Prop cct, to allow for numerous code developments. I was wondering if you could modify one to allow for the Proptool load, whilst it is low, and then raise it into protected mode, whilst still powered (ie a pull up resistor and a removeable link). Then the power cycling shouldn't affect it. If it is that then the line of code will have to be tracked down.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Style and grace : Nil point
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2010-03-07 20:25
    Joms,

    When you're operating from EEPROM, do you also have your USB cable unplugged? I'm just trying to rule out the phantom reset issue that plagues designs using unbuffered FT232Rs. If it works with the cable plugged in, but not with it unplugged, there's a simple workaround: add a 1K pullup to pin A30.

    -Phil
  • JomsJoms Posts: 279
    edited 2010-03-07 20:32
    Toby: It will be a little hard, but I will give it a try. Anything is worth a shot now. I am actually thinking now that my breadboard was doing the same thing, and I was thinking it was a connection, so I will play with it on the breadboard and it should be much easier.

    PhiPi: I am doing it with the USB pluged in. The device is actually USB powered, but now that you are saying these things, I don't remember this happening when I was using a battery. The 1K goes between 5v or 3.3v and pin A30 in what IC? The FT232R IC? I don't think there is a A30 Pin, on the Prop, A30 is already VDD.

    Could you help clerify where that resister goes? Also, I am using a transitor, cap, and resistor just like is shown on the Prop Plug schematic. Am I doing something wrong here?
Sign In or Register to comment.