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

Topics - deeaitch

#1
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
#2
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
#3
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
#4
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