Main Menu
Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - deeaitch

#1
LPC2xxx / Re: Failure when ISP programming data
June 29, 2009, 12:41:52 AM
Ofcource, how stupid of me... Here is the map file generated after linking in Rowley Cross studio.

/D
#2
LPC2xxx / Re: Failure when ISP programming data
June 25, 2009, 11:59:34 PM
Here comes the file

/D
#3
LPC2xxx / Re: Failure when ISP programming data
June 25, 2009, 12:24:33 AM
Andy.

I think I have located were the programming goes wrong... At this location:

            for(no_of_param=0;no_of_param<NO_OF_ISP_PARAMS;no_of_param++)
            {
                *(param_buf[no_of_param]) = 'z';    //When executing this line, the CPU goes to dabort_handler
            }
in isp_iap.c.

In assembler the code looks like this:
*(param_buf[no_of_param]) = 'z';
      E51B201C   ldr r2, [r11, #-0x01C]
      E59F31C8   ldr r3, [pc, #+0x1C8]
      E7932102   ldr r2, [r3, +r2, lsl #0x02]
      E3A0307A   mov r3, #0x0000007A
      E5C23000   strb r3, [r2]                           //At this line the problem comes.

Any ideas why?

Regards
#4
LPC2xxx / Re: Failure when ISP programming data
May 19, 2009, 11:36:26 PM
Hi Andy!

Thank you for the info and your time testing. Sounds strange that it works with LPC2388 but not with mine 2366...
I will continue to try identify the problem too.

Regards
#5
LPC2xxx / Re: Failure when ISP programming data
May 18, 2009, 11:37:10 PM
Hi Andy!

Thank you for your answer! Here comes the WEB.hex file.

http://forum.flashmagictool.com/index.php?topic=3601.msg4665#msg4665

Regards
Daniel
#6
LPC2xxx / Failure when ISP programming data
May 06, 2009, 11:32:20 PM
Hi!

I got the Ethernet connection working to my bootloader. FM successfully erases selected flash blocks and FM can read the flash memory of my LPC2366 on my own PCB board.

But... When it comes to writing the new .hex file to the flash something goes wrong.
The message Operation Failed. (programming - failed to send data to the device) pops up and the procedure stops. (Allthough FM reports Finished at the status field at the bottom of the program).

The erased flash blocks are the ones used by the new .hex file. Block 5 - 10.

I managed to run the UART debug to see what happends during flash write. This is what happends:

LPC Rx: U 23130
LPC Tx: 0
LPC Rx: W 1073742336 512.
LPC Tx: 0
LPC Rx: ...Data...
...
LPC Rx: ...Data...
LPC Rx: 44524
LPC Tx: OK
LPC Rx: W 1073742848 512
Here it stops...

In the Rowley debugger, it seems as the code runs into a dabort_handler.

Any ideas?

Please see the debug file attached.

Regards
#7
Hi Andy!

Thank you fow answering. I have not changed the emac.h file, just deleted some definitions that already exists on the LPC2366.H file that I use. The definitions were the same.

One thing I had to change in emac.c was the alignment of the rxbuffer[], because the pointer txptr in void WriteFrame_EMAC(unsigned short Data) pointed at the wrong non-even address. Anyway, when I aligned the buffer, the pointer writes at the correct location. I guess this is a compiler issue.
I will check for simular problems and write you an update...

Happy Easter!
/D
#8
Hi!

I have downloded a Ethernet bootloader to my LPC2366 +National PHY. I know that the hardware works because I can run my app. on it.
After adapting the emac.h, sbl_config.h etc. I downloaded the code to flash 0x0000000 and run it.

I try to run a "Blank check" or simular in Flashmagic but it respond with "Unable to communicate" and I can see in my Ethernet sniffer that a '?<CR><LF>' was sent to the correct MAC address in a UPD frame.

I debug the bootloader and it seams as the code does receive characters, but they are not processed....(?)
What else do I have to think about when "porting" the code to my LPC2366?

An other thing I can see when debugging is that the row memcpy(HostMAC,FRAMEr->source,6); is never reached when trying to connect. I can see that the function same_mac() always return false because HostMAC[] is 0. In fact, when placing a breakpoint in the emac_getline() function, I can see that the emac har received the frame from the host. Is the Ethernet bootloader propery coded?

I use:
Rowley Crossworks
CrossConnect tool
LPC2366 running at 70MHz via PLL, XTAL = 20MHz. (I have setup the PLL correct, and the timer in timer.c runs well with the millisecond intervals).

Happy for answers!
/D
#9
Hi Andy.

I think I got it to work now... And the hex file for the ethernet bootloader is ~50kB! Is it not a bit to large you think?

/D
#10
Hi again Andy.

Ok, I will check alternative ways....

Thank you
/D
#11
Hi Andy and thanx for the reply.

Ok, I will test that solution....
Hehe, well, 0x15B3 is much lower than what I get in Rowley GCC tool. Strange how big difference it is, perhaps there is something wrong there to...
I will test and coma back here again.

Btw. In the application note, both the bootloader and the application code seams to have a Startup.s file included allthough only the folder is shown in one of the cases. When I am thinking about it, shall it not be only ONE startup.s (located in the bootloader code)?
Also, there is a difference between the two LPC2300.s files used by the bootloader and the "Blinky" application... I am trying to see what the difference is, allthough I am not an assembler expert.

Rowley IDE uses Philips_LPC230X_Startup.s as startup file and that is what I have replaced LPC2300.s with. My early guess is that there is a smelly fish somewhere in this file...

I have digged more into what happends at the jump from the bootloader to the app code. Here is a screen dump of the assembly:

    user_code_entry();
      E51B3010   ldr r3, [r11, #-0x010]
      E1A0E00F   mov lr, pc
      E12FFF13   bx r3

When the code reaches the last row above, it jumps to the correct address 0x00005000 were hte following code is:
E59FF018   ldr pc, [pc, #+0x018]

Now, when executing the row above, the code jumps to address 0x00005318 were the following line is:
EAFFFFFE   b 0x00005318

I will write more when I have found out more.... brb
#12
Hello.

In sbl_main.c, located in the installation package of FlashMagic (in the Ethernet bootloader folder), the CRP shall be set in flash memory according to:

const unsigned crp __attribute__((section(".ARM.__at_0x1FC"))) = CRP;

But even if I add a Flash memory section in the memory map file, the linker sais that the memory ares is overlapped by .data section.
Now, how do I write this constans data into the flash memory location 0x1FC were the rest of the bootloader code is located?
Btw, I am using Rowley CrossWorks IDE.

Regards
D
#13
Hello!

I am new at the bootloader thing, so perhaps it is an abvious answer to my problem...

I am using the Ethernet bootloader code found in the installation package of FlashMagic. My device is LPC2366 running at 70MHz.
My main application is a FreeRTOS application with a bunch of tasks.

Equipment:
LPC2366 +Phy for Ehternet
Rowley IDE + CrossConnect USB debugger

First things first, the application note AN10744 sais that the bootloader requires the first 0x00000000 0x00002000 flash memory range. But when I compile the code demands much more. Is it normal? Is it my GCC compiler that is less good than others?

Well, well, now to the real problem...
I locate the bootloader at flash address 0x00000000 and the main application at 0x00005000, setup the sbl_config.h with the proper parameters and download the two codes to their dedicated places. (I place the app code at 0x00005000).
Now, when the device is reset it shall start the app code, but it does not.

Just for testing, I have cut out the bootloader entry functions and just place the execute_user_code(); at the sbl_main() start. When looking at the dissassembly, it looks like the bootloader jumps to 0x00005000 as it should. But then it stops in a loop.

The main app is set with
#define VECTORED_IRQ_INTERRUPTS
#define SRAM_EXCEPTIONS
in its startup.s file.

I guess much more info is neede here, but so far, is there any obvious reasons why the bootloader does not fire up the main application at 0x00005000 as it should?

/D