Program failling in the second execution when it is burned in flash

Hello Brad, thanks a lot for your answer. I am trying to do it right now, the problem I have is that I am using the tools suggested to generate a new *cfg.cmd file, with a different name, but I do not know how to indicate the building process to take this new *cfg.cmd, instead of the old one. Any tips about this? 

I have already solved this

When I try to follow the steps of the link of Brad, I obtain the next error:

 error:
               fill value for SECTION '.bss' redefined

It seems in some way I am trying to fill twice the .bss section, and CCS does not allow this. Someone could say me how could I solve this?

Thanks in advance

Hi again, finally I was able to fill unitialized sections, unfortunately still have video not working. Someone have more suggestions? We do not know what more could be checked.

Thanks

James,

Will you please post what caused your other issues (e.g. why the uninitialized sections weren't getting filled)?

Please clarify on what you mean by "the second time"?  How are you getting to the second run?  Power cycle? Reset?  Branch to _c_int00?

If you're having trouble with the video I recommend dumping the video port registers for the 2 scenarios and comparing.  Here's an applicable wiki page if you haven't seen it:

http://tiexpressdsp.com/wiki/index.php?title=Debugging_from_Flash

Brad

Hi, when I say the second time that board start running, I mean that we turn off the power, and turn it on again. We just have the flash burned so, it only starts again. I already knew the link that you wrotte, in fact if we use that technique "debugging from flash", as we load gel, we don't have any trouble with video, it looks like there is something in gel fixing our trouble. I have tried to add the gel initialization to our main() but unfortunately did not work.

We are trying to see the contents of video registers, but is complicated as we can't connect with CCS, as I said, this makes the board work properly and we would like to see when she is not.

James,

Can you please share what the issue was with initializing the uninitialized sections?  I am much less motivated to help you if you cannot share what was causing your problem(s).

Remove the gel file from your cc_setup when connecting with CCS and then check out the video port registers.

What boot mode are you using?

Brad

Well, sorry about forget to mention the "issue" about initializing the uninitialized sections, butI did not have any real issue with it. I had "programming" problems to follow the steps that you mention, because of build and link process, but I did not find any issue when finally I was able to fill these sections (finally I just did it like the link suggest to do it in a non-DSP bios project: in .cmd file just add "    .bss:     {} > DDR2, fill = 0xFFFFFFFF. Although my project is dsp-bios based, it only gave me a warning in the compiling, and I checked the map file, and I saw it was well filled).

Can I debug from flash without the needing of load gel? This was what I was wondering a few minutes ago, I will check it tomorrow.

We are using fast bood mode with ais

James Thorton said:

Well, sorry about forget to mention the "issue" about initializing the uninitialized sections, butI did not have any real issue with it. I had "programming" problems to follow the steps that you mention, because of build and link process, but I did not find any issue when finally I was able to fill these sections (finally I just did it like the link suggest to do it in a non-DSP bios project: in .cmd file just add "    .bss:     {} > DDR2, fill = 0xFFFFFFFF. Although my project is dsp-bios based, it only gave me a warning in the compiling, and I checked the map file, and I saw it was well filled).

Thanks for the info.  I believe using the "fill" command in the linker command file will bloat your code image because it specifies that data for each and every byte.  The "BIOS method" will simply loop through the section filling it with 0xFF.

James Thorton said:

Can I debug from flash without the needing of load gel? This was what I was wondering a few minutes ago, I will check it tomorrow.

Yes, definitely.  That was my intent in the "Debugging from flash" page.  Perhaps I need to make this more clear?

James Thorton said:

We are using fast bood mode with ais

Are you using the hexAIS.exe that comes bundled inside the DVSDK to create your AIS image?  Have you modified DM6437.ini with your corresponding PLL, DDR etc?  If not, you should!

Brad Griffis said:

Are you using the hexAIS.exe that comes bundled inside the DVSDK to create your AIS image?  Have you modified DM6437.ini with your corresponding PLL, DDR etc?  If not, you should!

Brad Griffis said:

Thanks for the info.  I believe using the "fill" command in the linker command file will bloat your code image because it specifies that data for each and every byte.  The "BIOS method" will simply loop through the section filling it with 0xFF.

Oh, that's bad... I will try again so the another method, but I really have a lot of problems to build my application following those steps, for example, when I use zeroInitSectionsCmdFile.tci, I am told to do something like : zeroInitSectionsCmdFile ("myappcfg.cmd", "newcfg.cmd"), creating a new cmd. Then I needed to told CCS that he needs this new cmd file, and that's where I had problem, I found how to do it, but it seems there was more files depending of the old cmd, or being generated with that one... I do not know exactly but I really had problems, so after two hours I tried the other method, and as I saw that .map was well filled and I guessed although some warning could work... as I say I will try another time the zeroInitSectionsCmdFile

Brad Griffis said:

Yes, definitely.  That was my intent in the "Debugging from flash" page.  Perhaps I need to make this more clear?

No, don't worry :). I was not sure that I was able to do it, as the page talks about being careful with gel file, so I thought that you were sold to use it, always taking care that could have effects in your debug. I have used the debugging from flash several times before, but I could not say if I loaded the gel... I guess that I did as I am usual to do it, and I did not need an hard debugging.

Brad Griffis said:

Are you using the hexAIS.exe that comes bundled inside the DVSDK to create your AIS image?  Have you modified DM6437.ini with your corresponding PLL, DDR etc?  If not, you should!

Yes, I did it, in fact before to do it, the program was not able to run.

So, finally it seems that the only thing that I can try again is filling memory with the other method, right? Thanks a lot for your answers

Hello, more news... if I debug from flash without loading any gel... we can see the video! so.. what is the differences when I load the symbol versus when I don't do? That could be the clue for our issue

Glad to hear you are able to see video! Note that loading symbols should not have any functional changes (that I can think of). Loading the project symbols simply allows the debugger to display symbol names meaning it can translate the disassembly output and point to the source equivalent.

TimHarron said:

Glad to hear you are able to see video! Note that loading symbols should not have any functional changes (that I can think of). Loading the project symbols simply allows the debugger to display symbol names meaning it can translate the disassembly output and point to the source equivalent.

So... basically... I can not do anything? [:S] Well, the video works, but as I say only if we load the symbol, as soon as we made a "clean" start up with it, our video dissappear again. One thing that we have noted, is that if when the application is already running, if we load the symbol, the video won't work again, which means that at least the symbol need to be loaded before run the application (so the problem could be in the initialization). But anyway, this is desperating issue... no sense, nothing to check, nothing to try.... :( Any more help?

Best regards

Connecting with an emulator and loading symbols will not change the behavior of the code.  Can you detail your procedure for connecting?  Something like this:

• Wait x minutes.  (How long do you need to wait for first execution to work?)
• Power on board.
• Connect with emulator, no gel file.
• Run.   (Doesn't work at this point with no symbols loaded?  Did I understand you right?)
• Halt.
• Load symbols.
• Run.  (Magically works?)
• Halt.
• Disconnect.
• Power cycle.
• Works?  Doesn't work?
• Connect.
• Load symbols.  (Works?  Doesn't work?)

There's lots of stuff to try.  Just stick with it and you'll figure it out.

For example, you may want to make a massively stripped down project.  Blink an LED using a PRD and verify with a scope that it's toggling at EXACTLY the frequency you think it should be.

Brad

Hi Brad, thank you for your support. I am going to describe you the more precise I can our steps:

-Application works well, except she is not able to capture the video that is being supplied via VPFE (and of course we have checked that there is always video).
-We erase and burn the flash. Power off and power on the board. Works everything perfect.
-Power off and power on the board. Application works but as I said without the capability of video.
-(*)We connect CCS, no gel file, and load symbol. If we keep running our application from the point it was, still not video
-We restart from CCS (Ctrl+ Shift + F5) and then ... voilá... video works again.
-We disconnect the CCS. Power off, power on. Application works, but guess what? exactly, video not working again.
-If we go back to (*) we will experiment the same results.

I am thinking... when CCS is connected I believe that could happen somekind of collateral effects due to communication process between pc and board... I said this, because I had trouble in the past where my application did not work perfect when I have CCS connected, but smoothly when I disconnected... Could be somekind of these "effects" fixing my issu?

Regards

Are you failing to wait for some power supply stabilization/reset line/initialization/etc?  I could especially see you trying to configure a video source before it has come out of reset or before a bus (especially i2c) has stabilized, so your "green screen" may simply be because you flew through an initialization routine before your source was ready.  Can you put an extended dumb wait of a few seconds as the first thing your code executes and see if that makes a difference?

Thanks both of you. You were absolutely right! We made a software reset by code and now is working perfect (and I am very happy :D ) Eventually we will need to check exactly where is the problem, and make the particular initialization that goes bad later.

Thanks again