Activating chip selects...???

I'm not sure why CS4 is not going active but I do know that CS0 is the "default" chip select. This means that if there is a memory access that does not fall within the range of the other chip selects, CS0 will go active.

You can use the definitions in absacc.h of the keil/c166/inc directory for direct access to external memory.

-Walt

I use the '167 but I assume the '161 is similar. You need to do several things:

1) If you are using UV2 to debug and are downloading to a target, you must revise the monitor you use to set up the chip select. If you have a common target development board, look in the Keil\C166\Monitor directory for the appropriate folder, go into it and start the UV2 project. Modify the config.inc file to set the bus settings for CS4\, then rebuild. This assembles and links the monitor before copying it to a default location. You must then select that monitor in your regular project under the debug/settings button.

2) You must setup the chip select in the application startup.a66 file.
This should enable the CS4 line. You can look at it's settings in the peripheral/system pulldown when in the debugger mode.

Best
Scott

Yes, it's most likely out op scope. I tried to shift the CS4 window around, but even starting at 0x000000 made no difference.
I'm not using any monitor at this point... just compiling it into a hex-file and uploading it to the target board. The program seems to run o.k. apart from the external CS's.
Registers are set like this:

FCONCS4 = 0x0021
TCONCS4 = 0x692B
ADDRSEL4 = 0x0400

included :
#include <absacc.h>
and
#define myvar HVAR(unsigned int, 0x40000)
for direct access, which seems to work also, because it writes to external address-space....
What am I overlooking?

Frank

Frank,

If you include absacc.h don't need the line...

#define myvar HVAR(unsigned int, 0x40000)

HVAR(0x45, 0x40000);

Have you configured the CS4 pin as an output? That is the only other thing I see that needs to be done.

Using HVAR this way seems to trigger a lot of syntax errors...don't know why.
I'll check the IO-pin settings....

Walt,

I'm afraid I messed up my code...guess it's getting late over here.
The device was configured with the help of Infineon's "Dave2.1"(well, you have to start somewhere)
Strangely enough Dave sets the direction of the CS-pins to input when configured as CS's! I have no clue why...

Well, tomorrow is an other day.
Thanks so far.

Frank

O.k. i think I may have found the problem....
It looks like a problem with the Start_V2.A66 file that Keil generates.
I think the following macro is not accurate


CALC_ADDRSEL MACRO sym, adr, size
IF size <= (4*KB)
sym EQU ((adr >> 8) AND 0xFFF0) OR 0
ELSEIF size <= (8*KB)
sym EQU ((adr >> 8) AND 0xFFE0) OR 1
ELSEIF size <= (16*KB)
sym EQU ((adr >> 8) AND 0xFFC0) OR 2
ELSEIF size <= (32*KB)
sym EQU ((adr >> 8) AND 0xFF80) OR 3
ELSEIF size <= (64*KB)
sym EQU ((adr >> 8) AND 0xFF00) OR 4
ELSEIF size <= (128*KB)
sym EQU ((adr >> 8) AND 0xFE00) OR 5
ELSEIF size <= (256*KB)
sym EQU ((adr >> 8) AND 0xFC00) OR 6
ELSEIF size <= (512*KB)
sym EQU ((adr >> 8) AND 0xF800) OR 7
ELSEIF size <= (1*MB)
sym EQU ((adr >> 8) AND 0xF000) OR 8
ELSEIF size <= (2*MB)
sym EQU ((adr >> 8) AND 0xE000) OR 9
ELSEIF size <= (4*MB)
sym EQU ((adr >> 8) AND 0xC000) OR 10
ELSEIF size <= (8*MB)
sym EQU ((adr >> 8) AND 0x8000) OR 11
ENDIF
ENDM


Address values are shifted 8 bits to the right(?) instead of 4 bits to the left!
(right 4 bits repr. size)
Things seem to work fine after this correction.
I hope I won't encounter more surprises like this...

Frank

The startup code allows you to specify the address as plain number, i.e. 0x400000. However, the ADDRSELx registers need just the A12 .. A23 address bits (number of bits depends on the window size). So your problem must be related to the way you specify the address in the START_V2.A66 file.

We never had problems before, but maybe we should clearify a comment somewhere, so that people put real address values.

Yes, I already figured that one out.
The problem however, is that I did not specify the address in the START_V2.A66 file. It was generated by Dave2.1.
So, I guess there must be a problem in the compatibility there!
I already wrote you an email about this matter.

Thanks anyway
Frank

We did not got your email. Please send the DaVE project you are using to:
support.intl@keil.com

Re: Activating Chip Selecet
Hello, we got a similar experience with the DAvE and I inspected the startup file.
There we found differences between _ADDR1 and _SIZE1 and resulting _RGSZ1. I have asked one of the authors of DAvE and it should be a misunderstanding, but we tested and it seems definitly wrong.
I wrote a second mail to DAvE author with more detailed explanation of startup file, I hope I get new answer and if something wrong I will post it.

Stefan

Stefan,
You have to manually adjust the startup file.
I don't know where the problem lies: with Keil or Dave.
Please do post any useful reply you may get from them.

Frank

Are you using the latest C166 and the latest version of DAVE?

I brought up this question to an Infineon guy and to our support guys and all of these issues were corrected a long time ago.

Jon

Frank,
as I promised, I post the answer from the DAvE authors.
The original message is written in german, so I try to translate.
DAvE generates a *.dpt file, which is used by the KEIL IDE to generate a project.
Within this *.dpt file all register bitfields and bits are listed with there actual values.'Here e.g. you find that the values of ADDRSEL1_RGSAD1=256 and ADDRSEL1_RGSZ1=5 are.Exactly the registernames as given by Infineon here are used.Now it is in the responsibility of the kEIL IDE to adapt the startup file in the right way. This is not under DAvE's influence. We are sorry that we can not help you in this case, but this problem has to be solved by KEIL .

I do not know, whether original message is usefull, so I do not post here.
I work with two activated CS and 2 address lines ( A16...A17 ) via EBC for an SRAM and it works.
- Stefan