Thank you for the replies. I will answer the items raised shortly.
Posting to this thread made me think about the problem, just like explaining a bug to a colleague at work. You often see the reason for the bug before your colleague does!
I now understand the problem with the ICU not working, however the apparent tristate behaviour of the upper address bits is still puzzling.
For non NS32000 family people, I should have explained that the ICU is the NS32000 family "Interrupt Control Unit". The NS32000 CPU family have an INT (active low interrupt pin) which can be used in a simple way, or as part of a vectored interrupt feature (sort of like the MC68000). The ICU supports the vectored interrupt feature and has 8 (or 16) interrupt inputs, either edge triggered or level sensitive. It can be wired to the CPU in either 8 bit mode or 16 bit mode. In 8 bit mode 8 pins are freed up and can be used as an 8 pin general purpose I/O port. This is what I have done and these 8 I/O pins connect to a LED bar. The ICU also includes some timers, which can be configured as 2 16 bit timers or combined as a single 32 bit timer (this is the mode I am currently using).
I am puzzled as to why National gave the user two options as I don't see a big advantage of the 16 bit interface over the 8 bit. OK some of the counter registers in the ICU are 16 bit so can be accessed a little easier/faster. I am also puzzled why they didn't take advantage of the AD15-0 (combined address/data) bus which would have saved the 5 address inputs. As compared to other timer/interrupt ICs, I always found this device a little confusing, perhaps not helped by the datasheet.
The mis-behaviour of the ICU and non lighting of the LEDs was caused by a software bug. My bad! In the very original ICU code I simply wrote to the I/O port. The default/reset mode of the chip is 8 bit.
Code:
9784 ;
9785 ; I C U R E G.
9786 ;
9787 ICUBASE: .EQU H'FFFE00 ; ICU REGISTER 0 ADDRESS
9788 ICU_MCTL: .EQU ICUBASE+16*2 ; ICU REG 16
9789 ICU_PDAT: .EQU ICUBASE+19*2 ; ICU REG 19
9790 ICU_IPS: .EQU ICUBASE+20*2 ; ICU REG 20
9791 ICU_PDIR: .EQU ICUBASE+21*2 ; ICU REG 21
9792 ICU_CCTL: .EQU ICUBASE+22*2 ; ICU REG 22
9793 ICU_LCSV: .EQU ICUBASE+24*2 ; ICU REG 24
9794 ICU_HCSV: .EQU ICUBASE+26*2 ; ICU REG 26
9795 ICU_LCCV: .EQU ICUBASE+28*2 ; ICU REG 28
9796 ICU_HCCV: .EQU ICUBASE+30*2 ; ICU REG 30
...
9884
9885 ;;;;;;;;;;;
9886 ; NS32202 ;
9887 ;;;;;;;;;;;
00004252 PC 9888 .ALIGN 2
9889 INITICU:
00004254 PC 54a500c0fffe28 9890 MOVB 0x00,@ICU_IPS ; ports are I/O
0000425b PC 54a500c0fffe2a 9891 MOVB 0x00,@ICU_PDIR ; ports are all output
00004262 PC 54a555c0fffe26 9892 MOVB 0x55,@ICU_PDAT ; initial pattern
This is what I recall working.
Nevertheless in investigating this problem I discovered the strange upper address bus anomoly and the horrid unexpected ICU chip select.
Poster @durgadas311 is correct when mentioning the importance of /RD and /WR. I forgot to explain that at the same time I saw the horrid ICU CS, both /WR and /RD were high/inative. So there should have been NO access of the ICU regardless of the chip select to the ICU. I (wrongly) assumed that this was causing the ICU to misbehave when it was a simple PEBCAK software bug. Nevertheless I don't feel comfortable having that waveform of chip select in my system.
I later added more code to configure the 32 bit timer. In doing so I wrote a '1' to a bit in the register which enables 16 bit databus mode! Further writes are interpreted differently as a consequence and the ICU registers are essentially corrupted. Simply changing this bit to zero resulted in the LED bar lighting and a nice squarewave being seen on the COUT pin.
Code:
00004269 PC 54a502c0fffe20 9893 MOVB 0x03,@ICU_MCTL ; 8 BITS INTERFACE,COUT OUTPUT,SQUARE WAVE,COUNTER OUTPUT TO PIN COUT
The MOVB value 0x03 should be 0x02 for 8 bit databus mode. 0x03 selects 16 bit databus mode.
As to /ADS. This signal is used to latch the address from the multiplexed AD15-0 pins into (usually) 74LS373 8 bit latches. It is generated by the TCU and indicates the start of any read or write cycle. It doesn't need to go into any chip select logic. In this case simply decoding the upper address pins to generate one or more chip selects is perfectly valid, and in fact I see this was done in a National application note for the NS32CG16. Any decoded chip enable also needs the /RD or /WR to be active in order to enable the selected chip/memory.
As to the comment "I don't know the NS32000 CPUs at all, but I'm not sure you can make any assumptions about the state of address lines in between the various control signals going active" this information is usually well documented in any CPU datasheet, and the behaviour of all pins, as to their input or output state is very well documented. This is particularly critical of any CPU databus, which by it's use switches between input/output/tristate/inactive modes. Since the NS32000 CPUs support various pins being tristated (using the /HOLD input) the behaviour of all affected pins is well documented. There is an added complication for the NS32016 if used with the NS32082 MMU, where the MMU used the CPUs /FLT input to tristate the CPU address in order to put its own translated address onto the main address bus (A24-A16 and AD15-0). In the case of no MMU the /FLT pin is actually an output called /DS (data strobe) and goes low whenever there is a read or write, sort of like the /TSO output from the TCU.
According to my interpretation of the datasheet, the upper address pins A23-A16 can be tristated, either when /HOLD goes low, or when the CPU is used with a MMU and the MMU forces /FLT low.
I checked with the scope, and I am seeing the suspicious rising level on the A23-A16 pins when the CPU status from ST3-0 is '0000', which according to the datasheet "0000 - idle CPU inactive on Bus". Hmmm, which bus? AD0-15 bus? AD23-16 bus?
Wow who would have thought? Perhaps in the idle status cycle ('0000') all data and address pins are really tristated? If this is really true then it isn't clearly documented in the datasheet. I have never seen it mentioned in any NS32000 documenation.
So poster @durgadas311 IS 100% correct with his statement "I'm not sure you can make any assumptions about the state of address lines in between the various control signals going active". I would have put money on the upper address bits always driving, even with the bus idle. I had assumed that the upper address bits would always drive (even during idle cycles) as this is what I have observed on other micros. Wow! Colour me embarrased!
I think that this now explains the upper address bit behaviour, and I need to consider adding pull-ups/downs, as a floating address bus is never a good thing.
Thank you for helping me think more clearly! 
Reply With Quote
Originally Posted by durgadas311
Bookmarks