Hello all,

I am working on a project using the at91rm9200 ARM processor, though in a custom embedded system as opposed to the Atmel development kit for that processor. My question is regarding the procedure to load the initial boot software:

I would prefer to load programs via a serial connection as opposed to JTAG. As best I can tell from the datasheet and related documents, the processor ought to be able to receive programs via the debug serial port, though I may be mistaken here. At any rate, I cannot get the processor to acknowledge or respond to anything on the serial line. Does anyone have advice regarding loading boot software (such as loader.bin, uboot, etc...)? As of now, we only have the internal ROM as memory to work with... also in the system will be 256 MB of NAND Flash memory (not yet installed). We do not want to develop the board further until we know the processor is working.

Chris

conger

You must hold PA31 (pin A10 on BGA) high during reset. The debug serial port (level shifted to RS232) will then send 'C' s as the start of an Xmodem transfer. I use Hyperterminal at 115200 8-N-1 (no handshake) and transfer a small boot program into the 16k of SRAM at 0x20000 (not remaped).

I wrote a small FLASH loader in about 8k (remember the top of SRAM is used by the Xmodem loader in ROM) which then did another Xmodem transfer of my code to FLASH.

I have a jumper on PA31 which is used if all goes wrong out in the field. But it is much easier to use the JTAG to get your code in

Good luck.

Could You send me some more information about your flash programmer. I made my own 9200 board and fall into same problem with programming flash. I used at49lv1614a (same as on atmel's 9200dk) and same sdram mapping, bootrom works ok but no succes with flash access - i followed AT91RM9200DK U-Boot Flash Programming Solutions - doc6041 and Booting U-boot form Atmel Serial DataFlash on the AT91RM9200-DK Board doc6067 only partially success loader.bin loads ok but no luck with u-boot.bin ;(

Greetings, JaSt

P.S. I can comunicate with board via USB - DFULoader so I belive that PLL works correctly, anyway no success with Jtag (wiggler + ocdemon)communication - no in debug mode error - any ideas ?

Hi JaSt

I was never able to get a Wiggler to use the JTAG interface. I did manage with a Raven and the macgraigor software. However I use Realview and we aquired a Abatron BDI2000 both for development and production. They work so well we would not go back to Raven.

The code I wrote was a Flash programmer that used the Arm Xmodem boot to load a boot loader that then loaded a programmer that then programmed the FLASH. We only use it if everything has gone wrong in the field and we need to start again. It was very heavily based on the Atmel Basic xmodem example and the FLASH read/write basic example. We just modified it for our FLASH chip.

I am not permitted to release the code but may be able to release parts if you require them. However they are very close to the Basics examples on the toolkit CD.

Hope this helps

hello Simon,

I'm very interested by your response because perhaps you can help me a little bit.
I use a boot program which works if I upload it after hardware reset directly in the internal sram via a jtag probe (it initializes plls, sdram, ... and then take an image from sdcard, copy it in sdram and jump into it).
My problem is that if I program the TWI eeprom with the same code, it does nothing. I think that the problem lies with the fact that internal rom code already initialize pll and other stuff and then my boot program becomes inconsistent.

Please have you any clues ?

I use the TWI with no problems.

My init called before MMU is basically this:
void AT91F_LowLevelInit()
{
AT91F_WaitForMainClockFrequency();
AT91F_InitFlash();
AT91F_InitClocks(PLLAR,PLLBR,MCKR);
AT91F_InitSDRAM();
}
The above very close to to the Basic code on the Basics examples.

Then I set up the hardware from main() :
void misc_init()
{
// Init Interrupt Controller
...................
// Open PIO for DBGU
AT91F_DBGU_CfgPIO();
// Configure DBGU
AT91F_US_Configure (
(AT91PS_USART) AT91C_BASE_DBGU, // DBGU base address
AT91C_MASTER_CLOCK, // 60 MHz
AT91C_US_CHMODE_NORMAL , PAR_NONE ,
// mode Register to be programmed
115200 , // baudrate to be programmed
0); // timeguard to be programmed
// Enable Transmitter
AT91F_US_EnableTx((AT91PS_USART) AT91C_BASE_DBGU);
AT91F_US_EnableRx((AT91PS_USART) AT91C_BASE_DBGU);
AT91F_DBGU_Printk("\n\rLow Level Init Complete\n\r");
PIO_Setup();
TWI_Setup();
wait(100); // give time for print above.
Dongle_detect(); // Internal code on my project
AT91F_EnableDCache();
AT91F_EnableICache();
AT91F_DBGU_Printk("Processor caches running\n\r");
}

At this point the whole ARM is running and I get on with the job.

I use this basic startup on all my projects.

I found a few delays in the code allowed things to stabalise, hence the wait(100); above.


My main() looks like this

int main()
{
unsigned int count;
char buf[8],img[32];

misc_init();
wait(100);
AT91F_TWI_Read(AT91C_BASE_TWI, 25, (char *)&img[0], 6, eprom); /* read it */


.....etc

The TWI is working fine.

Hope there is a clue in the above. I know it took me about a week to get TWI working properly.

Good luck

Simon, many thanks for your reply.

I nearly finished adopting DataFlash programer to our paralell, I hope it works correctly.

I noticed that we connected jtagsel pin high and I belive it coused our problems. Will dig it tommorow mornig and report my afforts.

Greetings, JaSt

thank Simon for your code.
Mine is almost the same, I think it doesn't work because of the PLL settings because i'm currently using a Cogent board and It seems to stuck in the AT91F_InitClocks(PLLAR,PLLBR,MCKR) function. I have to change the define for PLLAR, PLLBR and so one because the board has not the same quatrz as the atmel dev board. Perhaps the internal boot code has problems with other settings than the official atmel board ?

HI calimero,

I am using the cogent CSB337 eval board with the USB driver codes from Atmel site. And I found that the USB part does not work too. Have you got it to work?

Rgds,
kas

hello kas,

today one of my colleague try to implement usb device drver on the cogent board. We aren't successful now but we see that you have to change at least a little bit the atmel usb example because the PIo used for device detection is not the same on ATMEL DK board and on cogent board. you have to look at the spec to change this io accordingly.

Please tell we when you are successful with your usb implementation.

today I wonder if the USb pll is set correctly by the micromonitor embedded in the cogent board.

hi calimero,

yes, a change is needed for the pull up at the original code here.

=====================================
// Enable UDP pullUp (PIOA10 on AT91RM3400DK)
:
:
=====================================

After this change, I have checked most of the interrupts and usb registers. They seems ok, however, the usb is still not functioning. One thing is that the usb interrupt does not occur at all. But I do see that my host PC has an "unknown usb device" icon in the hardware device manager.

The only suspect is probably like the pll and oscillator like you mentioned. They seems alright. I woould like to guess this is the cause but just can't spot the problem yet.

Kindly let me know if you have anything. Thanks.

hi kas,
I can confirm you that the micromonitor embedded in the cogent board doesn't activate the pllB. so you have to set it manually (with writing the PLLBR register), I haven't the code with me but I remember you have to multiply the external oscillator by 26 (so you have to put 1 in the DIV field, 25 (26-1) in the MULT field an activate the bit that divide by two the frequency for usb (96MHz->48MHz))

after that we see the ENDBUSRES interrupt but with a strange behaviour.

Our driver is not working now, but we make one step in the right direction.

hi calimero,

thanks for this great tip! the usb is really working now and is being seen as modem device on the PC.