[mc1322x] CodeSourcery , flash loader

Tue May 11 22:26:07 EDT 2010

On 05/11/2010 01:32 PM, Mariano Alvira wrote:
> Can you try without thumb on?
>
> In config.mk:
>
> THUMB_FLAGS= #-mthumb -mcallee-super-interworking
>    
Turning off -mthumb seemed to make it work. But that was using 
arm-none-eabi-gdb, from CodeSourcery, version 6.7.50.20080107-cvs. Using 
their later verion of arm-none-eabi-gdb, 7.0.50.20100218-cvs, seems to 
work with -mthumb on.
So many very & so many methods, I feel like I am just making the 
situation more complicated.

When it works, it goes through a bunch of msr CSR instructions in _begin 
... is that the right behavior? Either way, it ends up branching to main.

There is still another problem, though: Once it reaches one of the for 
loops, it seems impossible to step out of them. 'until' seems to wait 
forever, as well as 'next' . Doing 'cont' runs the code properly, though 
(LED blinks). For both econotag and Jlink+redbee-dev.

Not to conflate the issue, but running the J-link GDBserver (windows 
app, inside a VM) also gives problems; this is with J-link -> JTAG 
connector redbee-usb on a dev board.
Starting pc at 0x400000, 'disassemble' shows that the code is there, but 
doing a 'si' only yields: '0x04004000 in ?? ()'. Maybe that's just a bug 
in their gdbserver. I tried their GDBserver because I thought it might 
handle stepping & breakpoint, like the above issues, better.

-Andrew

> The blink examples don't use the rom at all.
>
> My setup (which works with the example you asked about, both thumb and
> none thumb) is:
>
> Open On-Chip Debugger 0.5.0-dev-00027-g0324eb2 (2010-04-02-13:34)
> GNU gdb (GDB) 7.0.1
> econotag
>
> -Mar.
>
>
> On Tue, May 11, 2010 at 01:07:38PM -0700, Andrew Pullin wrote:
>    
>> More on this JTAG stuff. I updated OpenOCD, built it with libftdi 0.17-1
>> . No errors when inserting breakpoints.
>> But it still isn't working right, unfortunately. If I load the code with:
>>
>> target remote localhost:3333
>> monitor soft_reset_halt
>> set *0x80020010 = 0
>> load
>> monitor reg pc 0x00400000
>> continue
>>
>> then it'll run just fine (using blink-green_redbee-econotag.elf).
>> But if I set a breakpoint at main, it'll run to main() fine. But then if
>> I step instruction on the call to gpio_pad_dir(), the PC will end up at
>> 0x00000004, jump to 0x00400004, and fall though the undefined handlers
>> until it loads R0 into PC, and the OpenOCD console reports, "Error:
>> address + size wrapped(0xffffffff, 0x00000004)".
>>
>> Actually, as I was writing this, my J-Link EDU came in the mail, and
>> trying the same thing with the JLink + OpenOCD seems to produce
>> identical results: jump to 0x04.
>> So, any idea what's going on? Something to do with a call to a function
>> that's in ROM?
>> Sorry if this is something "obvious" ; I've never gotten JTAG to work
>> with a project before, and I always end up debugging-by-printf... so I'm
>> very interesting in getting this to work right.
>>
>> -Andrew
>>
>> On 05/06/2010 04:49 AM, Mariano Alvira wrote:
>>      
>>> On Wed, May 05, 2010 at 07:09:16PM -0700, Andrew Pullin wrote:
>>>
>>>        
>>>> On 05/02/2010 11:03 AM, Mariano Alvira wrote:
>>>>
>>>>          
>>>>>
>>>>>            
>>>> Ah, ok, OpenOCD seems to work, for the most part. If I connect via gdb,
>>>> I can load&   run a program as per the instructions on the site.
>>>> Unfortunately, debugging doesn't seem to be working? If I do a "break
>>>> main", and then "continue", it won't work right:
>>>>       Warning:
>>>>       Cannot insert breakpoint 8.
>>>>       Error accessing memory address 0x400982: Unknown error 4294967295.
>>>>
>>>> Single instruction stepping seems to work and output the proper source
>>>> lines, but OpenOCD occasionally generates "Error: address + size
>>>> wrapped(0xfffffffe, 0x00000004)" .
>>>>
>>>> I'm using a development version of OpenOCD, 0.5.0-dev-00191-gcc5f3c8,
>>>> built with --enable-maintainer-mode . Have you gotten breakpoints and
>>>> debugging to work fully?
>>>>
>>>>          
>>> Yes, that should work. OpenOCD does change and break stuff frequently
>>> though. What kernel are you running? There is a bug in the ftdi driver
>>> for the FT2232H that has been fixed since 2.6.31 --- it caused data to
>>> be lost randomly (also caused dropped serial characters). If you
>>> aren't running a newer kernel then I'd try that before trying a
>>> different version of OpenOCD.
>>>
>>> I know this commit is good: 0324eb24967088f753bc2fd997b4c18f4ea988c8
>>>
>>> So if it is Openocd you can bisect against that.
>>>
>>>
>>>        
>>>>
>>>>          
>>>>>> If the Econotag has onboard JTAG, does that mean that there's a way to
>>>>>> do a similar thing with the redbee-dev, not needed a JTAG pod?
>>>>>>
>>>>>>
>>>>>>              
>>>>> Yes, you plug in an EconoTAG and run:
>>>>>
>>>>>       openocd -f board/redbee-econotag.cfg
>>>>>
>>>>>
>>>>>            
>>>> That seems to work for the Econotag, but the small redbee + dev board
>>>> only enumerates one USB->serial device when I plug it in, which seems to
>>>> be the communication UART.
>>>>
>>>>          
>>> Ah, I think I misunderstood/misread your question. The module has it's
>>> JTAG pins on the top and no JTAG controller. The dev board doesn't
>>> hook into JTAG at all --- so for the redbee + dev combo you need an
>>> external JTAG pod.
>>>
>>> -Mar.
>>>
>>>        
>>      