C672x Flash access problem

Ah, yes, that makes sense, Tim.  Shouldn't be too hard.  Something like this I imagine:

uint32_t   read_flash32(uint32_t *pFlash)
{
    GPIO_OUT = (pFlash >> 13);
    return *pFlash;
}

This may change slightly based on which GPIO pins you hook up.  Same principle though...

Most code examples I have come across are for dev kits based on the 6727, which are using CPLD's or FPGA's for controlling the upper address lines to the async memory devices. 

We have a C6726 (tqfp) custom board with a 16-bit 29F800 flash.  Using SPRRS370B (Fig4-5) and SRU711B (Fig2-8b and Fig2-9b) as references, the upper address lines A13-A18 were attached to DSP pins AXR010-AXR015 (for use in GPIO mode).  From my limited understanding and using SPRAA69C as a guideline, once the AIS image is created from the application/bootcfg/TiSecondaryBootloader source code, the on-chip bootloader *should* handle accessing the async upper addressing via AIS commands during boot.

My problem is programming the FLASH in the first place!  Flashburn has been mentioned (softwaredesignsolutions) - which we have used previously on the C6713.  Along with the Flashburn Windows GUI, there needs to be "FBTC" software to run on the DSP.  On the C6713, this was easy as the all async address lines were provided and dedicated. 

Since the FBTC would require customization and the C6726x requires an AIS image - which can be used as easy as a HEX formated file - we created a DSP project that can read in a AIS file and program the flash device up to the dedicated address range (A0-A11).  That was fairly straight forward - I just do not have enough experience with the C672x GPIO pin's.  To better understand, can you elaborate on your code above?  Do you have sample code that you can provide, that sets up the GPIO pins to directly control the upper address lines?  Do you have code from the on-chip bootloader utility that can be viewed? 

Since you've connected McASP pins to the flash, you'll want to consult the McASP Reference Guide for details on how to configure the McASP in GPIO mode:

http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3&tabId=409&familyId=1404&abstractName=spru878b

The procedure is described in Section 2.8.2 "GPIO Pin Control".  Your code to configure the pins as general purpose outputs should look like this:

McASP0_GPIO_init(void)
{

// set AXR10-15 as GPIO
   PFUNC = 0x0000FC00;

// set AXR10-15 as outputs
    PDIR = 0x0000FC00;

}

To actually write to an address in the flash you would do something like this:

async_emif_write(uint16_t data, uint16_t *pFlash)
{
// data is the 16-bit value being written on the EMIF bus
// pFlash is a pointer to the flash (e.g. 0x90000000 corresponds to the start of the flash)

// set AXR0[15:10] based on address bits 19:14
// mask off bits 19:14 then right-shift 4 to align with bit 10 of POUT reg
   POUT = (pFlash & 0x000FC000) >> 4;

// now that GPIO pins are correctly set, do the write
*pFlash = data;

}

So using the above code (or something similar) will make the EMIF look as if it has more address pins.  If you do a lot of sequential writes to the same "page" of memory then you could optimize the code by not doing so many writes to the POUT register.  It might be simpler and less error prone to just always write the POUT register just in case.

 ...continuing along with the example above (which was extremely helpful, thanks)...but now focusing on the secondary bootloader process.

Since GPIO are required for addresses above 0x90001FFF, I assume this is what TI is referring to as a "page boundary".

When the AIS data stream is created, the SWAP_PAGE_COMMAND (0x585359F1) is only called once (prior to address 0x90008000), and then again to clear the GPIO registers at the end of the AIS file.  Since the TISecondaryBootloader.c controls the GPIO pins during a parallel flash boot via AIS commands, shouldn't this command be in the AIS data whenever the GPIO pins are required to change?   (aka  prior to accessing data at 0x90002000, 0x90004000, 0x90008000, etc...)   

(excerpt from AIS file)

    0x585359F1        ;Flash Address 0x90007FD4
    0x00000003        ;Flash Address 0x90007FD8
    0x44000010        ;Flash Address 0x90007FDC
    0x00000400        ;Flash Address 0x90007FE0
    0x00000001        ;Flash Address 0x90007FE4
    0x44000014        ;Flash Address 0x90007FE8
    0x00000400        ;Flash Address 0x90007FEC
    0x00000001        ;Flash Address 0x90007FF0
    0x4400001C        ;Flash Address 0x90007FF4
    0x00000400        ;Flash Address 0x90007FF8
    0x00000004        ;Flash Address 0x90007FFC
    0x58535901        ;Flash Address 0x90008000
    0x10005790        ;Flash Address 0x90008004

I'm confused as to where you got the page size of 0x2000 from.  On a C6727 device, there will be 15 address lines (EM_A[12..0] and EM_BA[1..0]) available when accessingan 8-bit ASYNC memory, 14 address lines (EM_A[12..0] and EM_BA[1]) when accessing a 16-bit device, etc.  This leads to page sizes of 0x8000, which the AIS generator and the TISecondaryBootloader is set to handle.  If you are using on a device where the EM_A[12] pin is not available (maybe your C6726 TQFP), then page sizes would have to be 0x4000, but I don't know if the software allows you to specify a new page size.  If not, then modifying it probably wouldn't be too difficult.  I think the AIS generator is the only component that would need to be modified - I'm pretty sure the TISecondaryBootloader could stay as is.

Regards, Daniel

We are using a C6726 (tqfp) with a 16-bit 29F800 flash attached (as suggested in SRU711B Fig2-8b) where A11..A0,BA1 (DSP) are attached to A12..A0 (FLASH), respectively. 

Since we are using a 16-bit data bus, BA1 is always "0" (byte writes are inhibitied, so we are always accessing even address locations...0x90000000, 0x90000002, 0x90000004, etc...).  From the perspective of the FLASH device:  (A12..A0) = 2^13 = 8192d = 0x2000 address locations; or with binary (A12-A0) = 1 1111 1111 1111 => 0x0000 - 0x1FFF address range (aka - page size).  So, in order to access 0x90002000 and above, the C672x GPIO pins for upper address lines A18..A13 need to be used.   Hence, we are using the -pgsize 0x2000 with the genAis.pl script.  

I found that there is a -pgsize option that can be used with genAis.pl...so in effect my question has been answered.  However, since the genAis script will work with -pgsize 0x2001 but errors out with -pgsize 0x2000, I started a separate forum thread to find out if this is a bug or a "deficient user knowledge" problem.

I think you may be misintrepting the use of BA1 when the EMIF is operating in 16-bit mode.  BA1 will reflect the second least significant bit of the logical address that the C672x is trying to acces.  So if you access 0x90000000, BA1 will be 0, but if you access 0x90000002, BA1 will be 1.  The memory region you can access with EM_A[11..0] and EM_BA[1]  will be 2^13 times 2 (since each physical access is for 16-bits = 2bytes).  So the page size in bytes would be 0x4000.  I was messing around with the tools that are included with the SPRAA69 document (in the sprc203.zip archive), and they appear to take into account the package type and the availability of the EM_A[12] pin to use the right page size (either 0x8000 or 0x4000).

Yes, you're right.  Sorry, I forgot to take into account that you were using a 16-bit flash device. So really rather than looking at address bits 18:13 we should instead have been looking at address bits 19:14.

// set AXR0[15:10] based on address bits 19:14
// mask off bits 19:14 then right-shift 4 to align with bit 10 of POUT reg
   POUT = (pFlash & 0x000FC000) >> 4;

I'll modify my earlier post as well.

We are using a C6726b with a 16-bit S29AL004D parallel flash attached (SRU711B Fig2-8b), where A11..A0,BA1 (DSP) are attached to A12..A0 (FLASH). EMIF is configured for 16-bit mode. 

In previous posts it was said that BA_1 - 0 at addresses 0x90000000, '1 '- 0x90000002, etc. 

But we have, as I see BA_1 always '0 'for any address. The command to write to this flash consists of four cycles in which we are need to access to the address 0x555 (10101010101), 0x2AA (1010101010), 0x555 and the desired address. But BA_1 is always '0'. Maybe I misunderstood something? 

And another question: Where can I find detailed information about the ROM bootloader?

A1CR register value is 0x3FFFFFFD;

Here is my code to access Flash:

Uint32  t;

.......

t = *(Uint32*)0x90000000;

t = *(Uint32*)0x90000002;

t = *(Uint32*)0x90000004;

.....

Do you see 3 accesses occur on the bus?  What pins are toggling?  You should make your pointer "volatile Uint32*" so that the compiler doesn't try to optimize these accesses.

Thanks for the tips. Pointer "volatile Uint32*" does not change the situation

But I accidentally put Uint16 type, and everything worked fine.

Uint32 t;

.......

t = * (Uint16 *) 0x90000000;

t = * (Uint16 *) 0x90000002;

t = * (Uint16 *) 0x90000004;

.....

Now I see change BA_0.

Problem solved.