|
I've been working with some boot code that I wrote and it's been
working beautifully for months. I basically just opened up the gel file to get the needed EMIF values and addresses, then initialized that and did my copying. But now I'm having a problem, and I have no idea why. What I did was add some HWI's. Then I got a warning that my stack size was too small. I naively ran it once just to see what would happen. It didn't work, so I increased the stack size. But it still didn't boot. Played around with it some, but it still didn't work. So I went back to my old code and programmed that into the flash, and that didn't boot either. I'm pretty positive that the same code was working a couple weeks before. So, then I started stepping through the code. While I'm initializing the EMIF interface, I go to do a stw to one of the registers and the DSP jumps (maybe resets? But I don't think so) to a point earlier in the boot code. So effectively, whenever I store this value it just jumps me to a previous spot in the code. It's just a standard EMIF register that I'm writing this to. I've tried stepping over the bad portion. Sometimes CCS crashes (telling me that it's possibly corrupted memory or a stack overflow), other times it lets me, but since I skipped a step, the EMIF doesn't initialize and everything is worthless. I've ran all the diagnostics included, and everything checks out. So, my question is does anyone know of any peculiarities that smashing a stack might have that would cause this behavior? Does anyone know of anything that would cause this behavior? I thought I had seen this problem before when I had some grounding issues, but I'm pretty sure that's not the case now. Is there some setting I could have corrupted that a power-cycle would not get rid of? I haven't seen anything that jumps out at me. Lastly, is there some way to put the DSP into the factory default settings or anything? Possibly a way to just start anew? Any help would be appreciated, I'm pulling my hair out over this one. Oh, and I'm on a c6713 DSK. Mike Petty |
|
|
Boot Problem
Started by ●April 8, 2004
Reply by ●April 9, 20042004-04-09
|
This is kind of an update to the problem I was having before. I think that my problem has something to do with either the copy from the first 1K of flash to memory upon bootup or with the hex file translation. If I burn my program into flash, say a section of it looks like this (when I use the view flash contents option in flashburn): 00 29 AA 33 After burning, I reset the DSP and go into code composer, where I look at memory address 0x00000000. It's contents would look something like this: 0xFFFF0000 0xFFFF2929 0xFFFFAAAA 0xFFFF3333 Is that what is should look like? I can see how the translation is happening, but when I look at my assembly source in mixed mode, it doesn't seem to make much sense. I'm not sure that I even trust Code Composer to tell me what's right. For example, if I load the symbols, then it says the PC points to my first instruction, but then when it executes something like mvkl 0x05,B4 I watch the B4 register and it doesn't change. So, it's not even executing that instruction, but code composer shows that it is. This only happens on programs that are burnt to flash. Everything works on programs that aren't. Mike Mike Petty wrote: >I've been working with some boot code that I wrote and it's been working >beautifully for months. I basically just opened up the gel file to get >the needed EMIF values and addresses, then initialized that and did my >copying. > >But now I'm having a problem, and I have no idea why. What I did was >add some HWI's. Then I got a warning that my stack size was too small. >I naively ran it once just to see what would happen. It didn't work, so >I increased the stack size. But it still didn't boot. Played around >with it some, but it still didn't work. So I went back to my old code >and programmed that into the flash, and that didn't boot either. I'm >pretty positive that the same code was working a couple weeks before. > >So, then I started stepping through the code. While I'm initializing >the EMIF interface, I go to do a stw to one of the registers and the DSP >jumps (maybe resets? But I don't think so) to a point earlier in the >boot code. So effectively, whenever I store this value it just jumps me >to a previous spot in the code. It's just a standard EMIF register that >I'm writing this to. I've tried stepping over the bad portion. >Sometimes CCS crashes (telling me that it's possibly corrupted memory or >a stack overflow), other times it lets me, but since I skipped a step, >the EMIF doesn't initialize and everything is worthless. > >I've ran all the diagnostics included, and everything checks out. > >So, my question is does anyone know of any peculiarities that smashing a >stack might have that would cause this behavior? Does anyone know of >anything that would cause this behavior? I thought I had seen this >problem before when I had some grounding issues, but I'm pretty sure >that's not the case now. Is there some setting I could have corrupted >that a power-cycle would not get rid of? I haven't seen anything that >jumps out at me. > >Lastly, is there some way to put the DSP into the factory default >settings or anything? Possibly a way to just start anew? Any help >would be appreciated, I'm pulling my hair out over this one. > >Oh, and I'm on a c6713 DSK. > >Mike Petty >_____________________________________ >Note: If you do a simple "reply" with your email client, only the author of this message will receive your answer. You need to do a "reply all" if you want your answer to be distributed to the entire group. > >_____________________________________ >About this discussion group: > >To Join: Send an email to > >To Post: Send an email to > >To Leave: Send an email to > >Archives: http://www.yahoogroups.com/group/c6x > >Other Groups: http://www.dsprelated.com > >Yahoo! Groups Links > > |
|
|
Reply by ●April 9, 20042004-04-09
|
Mike,
Something is really messed. probably beginning with the hex
utility. It looks like maybe the "ROM width geometry" and your "ROM width"
[8] are different.
TIP:
To look at your actual FLASH code, use the handy addition to the 6711 DSK
GEL file below. A problem that commonly occurs is that you need to
configure the memory for "32 bit mode" to access the LEDS/Switches, etc. but you
need to configure it in "8 bit mode" to properly access the flash.
In 8 bit mode you should be able to view or disas mem at 0x90000000 to see
your code.
mikedunn
menuitem "Set_CE1";
hotmenu Set_CE1_8bit()
{ CE1_8bit; } hotmenu Set_CE1_32bit()
{ CE1_32bit; } Mike Petty <m...@nmt.edu> wrote: This is kind of an update to the problem I was having before. |
|
|
Reply by ●April 9, 20042004-04-09
|
My hex6x conversion cmd file looks like this: /*hex6x Conversion cmd file*/ -a -image -zero -memwidth 8 -map bootmap.map Debug/Correlator.out ROMS { FLASH: org = 0x90000000, len = 0x3fc00,romwidth = 8, files = {Correlator.hex} } SECTIONS /* list of COFF sections to be ROMed */ { .....(my long list of sections) } So, I have the romwidth and memwidth set to 8 bits. On my jumpers, I have it set to boot from FLASH at 8-bits. Maybe those dip switches are broken or something, I'll try to trace them through the board some and see if there are any problems. When I look at the memory at the start of flash (0x900000), everything looks good. My code is there and intact. It looks like the transfer from the flash into 0x00000000 that the DSP executes on every reset is messing things up. When the instruction should be 0x00000080, I get 0x00008080. The only problem I can think of is that the DSP is operating at the wrong memory width. But I don't know how that would happen. Mike Mike Dunn wrote: > Mike, > > Something is really messed. probably beginning with the hex utility. > It looks like maybe the "ROM width geometry" and your "ROM width" [8] > are different. > > TIP: > To look at your actual FLASH code, use the handy addition to the 6711 > DSK GEL file below. A problem that commonly occurs is that you need > to configure the memory for "32 bit mode" to access the LEDS/Switches, > etc. but you need to configure it in "8 bit mode" to properly access > the flash. > > In 8 bit mode you should be able to view or disas mem at 0x90000000 to > see your code. > mikedunn > > *menuitem "Set_CE1";* > *hotmenu Set_CE1_8bit() > { > CE1_8bit; > }* > *hotmenu Set_CE1_32bit() > { > CE1_32bit; > } > * > > */Mike Petty <>/* wrote: > > This is kind of an update to the problem I was having before. > > I think that my problem has something to do with either the copy from > the first 1K of flash to memory upon bootup or with the hex file > translation. If I burn my program into flash, say a section of it > looks > like this (when I use the view flash contents option in > flashburn): 00 > 29 AA 33 > > After burning, I reset the DSP and go into code composer, where I > look > at memory address 0x00000000. It's contents would look something > like this: > > 0xFFFF0000 > 0xFFFF2929 > 0xFFFFAAAA > 0xFFFF3333 > > Is that what is should look like? I can see how the translation is > happening, but when I look at my assembly source in mixed mode, it > doesn't seem to make much sense. > > I'm not sure that I even trust Code Composer to tell me what's right. > For example, if I load the symbols, then it says the PC points to my > first instruction, but then when it executes something like mvkl > 0x05,B4 I watch the B4 register and it doesn't change. So, it's not > even executing that instruction, but code composer shows that it is. > This only happens on programs that are burnt to flash. Everything > works > on programs that aren't. > > Mike > |
|
|
Reply by ●April 9, 20042004-04-09
|
This is just kind of a wrap-up to my problem. It turns out that the DSP had some damage to it that resulted in it default booting into 16-bit mode. The second dip switch has a pull-down network on it. The configuration of the second and third dip switch determines the c6713's boot mode. Well, I had a button hooked up to GP0 on the DSP. GP0 is also routed to the second dip switch. I guess that at some point, something happened and some parts were probably injured. Switching the DIP switch around, the voltage on the output didn't change (was a steady 1.75V). It should have gone between 0 and 3.3V. So, the DSP saw that switch as on all the time, which made it boot into 16-bit mode instead of the default 8-bit mode. If I ground the output of the switch, it does boot properly. So, if I keep GP0 grounded, it does boot properly. I haven't been able to get in and test whether all the other GPIO pins are working or not. I really hope that they're fine. Mike |
|
|
Reply by ●April 13, 20042004-04-13
|
Congrats Mike,
Sorry about some of my reply - somehow i got it in my head that you had a
6711 DSK instead of a 6713. Like most problems, your results make sense in
"hindsight".
A couple of "lessons learned" comments to the hackers out there:
1. Any C6000 device [except 6201/6701] reads some of the bus pins for
device configuration at reset. if you have hooked anything to the bus,
make sure that you know how/if it affects the device configuration.
2. If you are "hooking stuff directly to DSP pins" be aware that those pins
may never be the same again. the process of attaching a wire can blow the
part if you don't use "ESD caution" while working - of course i have to
admit that sometimes this falls in a "do as i say" category [:-)
Good Luck with your project, Mike!
mikedunn
Mike Petty <m...@nmt.edu> wrote: This is just kind of a wrap-up to my problem. It turns out that the DSP |
