XMEGA and FATFS

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All

I need to make a bootloader for my XMEGA. I am thinking about using FATFS or PetitFs.

My boot space is 8K, will FatFs be small enough?

How do I convert the current AVR samples for XMEGA? Do anyone have an sample?

I see there is a avr_complex and avr_foolproof.

I am thinking avr_foolproof is bitbashing? And AVR_complex is using hardware SPI.

What files must I change to get it work on XMEGA?

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FatFS will fit. To make it work you need to convert the SD card driver to use the XMEGA SPI. I did it a while back and it was pretty simple, but it's commercial code so I can't share it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I haven't tried this on Xmega but my SD bootloader:

https://spaces.atmel.com/gf/proj...

should almost work as is because it just bit-bangs SPI on 3 pins. See asmfunc.s:

https://spaces.atmel.com/gf/proj...

That would need modification to use Xmega ports (to continue to use SBI etc they'd need to be mapped as VPORTS).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just noticed FATFS in ASF wizard, has anyone tired that?

It seem only the low level functions are they and not spi configuration?

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think there are some ASF examples that include SPI stuff. The ASF example code is always worth checking out. In Atmel Studio go to File->New->Example Project.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ozhan KD
Knowledge is POWER

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok I got a good start with ASF, when compile i am getting 22K of flash data, how do I get the size below 8K?

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Ok I got a good start with ASF, when compile i am getting 22K of flash data, how do I get the size below 8K?

FatFs has ffconf.h which allows certain features to be turned on/off but 22K is a typical kind of size for an application using FatFs.

For applications where you want FAT access but code that is much smaller Chan (the author of FatFs) has a variant called "Petit". This will reduce the code to maybe 3-4K but some compromises are made.

When I wrote this:

https://spaces.atmel.com/gf/proj...

I effectively took Petit then threw away all the high level FAT code and wrote my own from scratch to do only one very specific single job (find and read a BIN file and use it to bootload). I have some configuration options. Using those it can be built under 1K but typically it is 1K..2K. I did this so it would fit in to the bootloader section of a mega16 or mega32.

If your goal here is to get an SD bootloader into an Xmega then I believe they have 4K or 8K bootloader sections so you should be able to achieve it using just Petit but if things are very "tight" you might want to explore my sdbootloader code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi

I am using the atxmega256a3bu

Ok, I have downloaded petitFatFs, and made project .

In the downloaded folder there is a folder called avr_boot.

IF I am correct this is a simple bit bash version?

I think I could just use this for my bootloader..

I have now changed the following, but it seems this is not the correct way of doing it..

#define	DDR_CS	_SFR_IO_ADDR(PORTD.DIR), 4	// MMC CS pin (DDR, PORT)
#define	PORT_CS	_SFR_IO_ADDR(PORTD.OUT), 4
#define	DDR_CK	_SFR_IO_ADDR(PORTC.DIR), 7	// MMC SCLK pin (DDR, PORT)
#define	PORT_CK	_SFR_IO_ADDR(PORTD.OUT), 7
#define	DDR_DI	_SFR_IO_ADDR(PORTC.DIR), 5	// MMC DI pin (DDR, PORT)
#define	PORT_DI	_SFR_IO_ADDR(PORTD.OUT), 5
#define	PIN_DO	_SFR_IO_ADDR(PORTC.DIR), 6	// MMC DO pin (PIN, PORT)
#define	PORT_DO	_SFR_IO_ADDR(PORTD.OUT), 6

When I compile i get constant value required errors..

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

anyone who can correct my syntax?

Further looking into petitFatFs

My hw setup does not have Card detect or write protection, can this be an issue?

What is the difference between avr_mmcp.c and mmc.c?

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What is the difference between avr_mmcp.c and mmc.c?

Virtually nothing as far as I can see (I compared using kdiff3). One seems to have modified some of the variable names to be slightly mores sensible names than the others.

But you don't want to be looking at the "avr" directory in pfsample.zip anyway. Those are all for chips like tiny45 and tiny85 and rely on using usi.S to drive the USI in those chips as an SPI interface.

A far better starting point is "avr_boot". (which is what I used as the basis of my SD bootloader) as it just uses 4 pin bit-bang to do SPI on any 4 pins you choose.

The latter would be easier to "port" to an Xmega than the former I think though I guess you could just re-implement the 4 routines in usi.S:

void init_spi (void);
void dly_100us (void);
void xmit_spi (BYTE d);
BYTE rcv_spi (void); 

As for using the bit-bang routines in avr_boot. To find out why your port definitions don't work I'd be looking at the .i or .s file output from -save-temps.

EDIT: actually I just started to do that -save-temps experiment and I think I see your problem. You have defined the ports with lines such as:

#define   DDR_CS   _SFR_IO_ADDR(PORTD.DIR), 4

but dot notation (struct member access) is a C only concept that cannot be used in a .S assembler source file. In fact in the iox*.h files you'll find the stuff that defines things like PORTD.DIR is under "#ifndef __ASSEMBLER__" (or whatever the test is) so that stuff simply is not visible when the assembler is used. This is the reason why Atmel have defined things like PORTD.DIR as PORTD_DIR as well. The latter *should* be valid in an Asm file. So change the '.'s to be '_'.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK I just tried that (. to _) and it hits the next error I already told you about. The code is full of SBI and CBI instructions. You cannot do that to PORTD_DIR, PORTD_OUT and so on with Xmega as those registers are not in range of the SBI/CBI instruction. So you have two options:

1) Change all the SBI/CBI to be LDS/[OR|AND]/STS

2) map PORTD to one of the VPORTs and actually make the code SBI/CBI to the VPORT locations.

To my mind (2) is much easier (and more efficient) than (1).

Or maybe it's best to use the "avr" version and just implement xmit_spi() and rcv_spi() to use the Xmega's real SPI?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So if i make Vport(need to google how to), i then associate that to my currents pins and specify the VPORT in the asmfunc.S.

If I stick to AVR version, i can just delete usi.S nad just create a new C file with the functions. example

#define xmit_spi(dat) 	SPIE.DATA=(dat); loop_until_bit_is_set(SPIE.STATUS, 7)

static BYTE rcvr_spi (void) {
SPIE.DATA = 0xFF;               // Set sequential mode
loop_until_bit_is_set(SPIE.STATUS, 7);
return SPIE.DATA;
}

In AVR folder, where to i initialize SPI and its pins e..g DIN,DOUT,CLK

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yeah,

That's an either/or.

You either use avr_boot version and change the setup in asmfuncs.S to map PORTD to VPORT0 (say).

Or you us the "avr" version and just re-implement the SPI send/receive routines to use the real SPI.

I'm guessing the latter could be the "better" option.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I will try the latter first,

What effect does VPORT have, do you have an example how to set one up.

In AVR folder, where to i specify the DIN,DOUT,CLK.

I also noticed CS is also read when writing, do i specify this a pin read?

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

What effect does VPORT have, do you have an example how to set one up

I think the very first thread I posted to Xmega forum was about VPORTs in fact.

What it does is map four of the key PORTx registers to VPORTn. Most of the Xmega SFR locations are up at 0x400, 0x500, 0x600 and addresses such as that. This is well out of the range of SBI/CBI and IN/OUT but by making the same registers appear down near the start of the SFRs it brings them back into SBI/CBI range.

Depending on the application there might always be an argument for mapping your most used PORTs down to VPORTs and accessing them there.

I'll see if I can dig out that thread I am talking about.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am starting with the AVR folder

What is FORWARD(rcv_spi());

/* Receive a part of the sector */
if (buff) {	/* Store data to the memory */
do {
*buff++ = rcv_spi();
} while (--cnt);
} else {	
do {
FORWARD(rcv_spi());
} while (--cnt);
}

Is this something related to the UART which i dont need? As in compile with that commented out otherwise it looks for the uart.s files and is associated header file.

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi I got it working.

Even though my CS select is on another port, the CS associated with SPI port must be forced high?

Just need to know if
FORWARD(rcv_spi()); is commented out, what effect would that have?

As i keep getting

implicit declaration of function 'xmit' [-Werror=implicit-function-declaration]

Thanks

Regards

DJ

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So why not look at the definition of FORWARD?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have to look into it deeply as it is spi related in a uart file.

Thanks

Regards

DJ