Hello All,

I have been trying to get past setting the chip selects on the MC68340 CPU. I can program pretty much everything on the CPU, but when I set the "V" flag of the CS0 Base Address Register (bit 0 of the CSBAR0), the CPU freezes. No errors, just freezes. I know this issue is related to the "Global Chip Select" that CS0 defaults to right after reset and before the "V" bit is set. Setting the "V" bit clears the Global Chip Select action of CS0 and switches it to be a "Normal" Chip Select.

I can configure CS1, CS2, and CS3 without issue but they aren't active while the Global Chip Select is active. I have followed the examples in the MC68340 User Manual, have read all of the User Manual Updates, and am unable to get past this point. Not much info or code is available on the net, and I really do need help getting past this step. I'm more of a hardware guy than a programmer, but this seems straightforward.

If I comment out the line that sets the "V" flag of the Chip Select Base Address Register, the remaining code (not posted) continues and seems to work correctly - just can't access any devices in the device map since the chip selects aren't active.

If it helps, I've swapped out CPUs with 25MHz and 16MHz versions both Freescale and Motorola versions, AND I did have the same exact issue on previous revisions of the PCBs. This project has two CPU (the other is a MCF5206) and I have no issues configuring the Chip Selects on the second CPU.

Any help or insight would be appreciated.

Thank You!

BAR           EQU $0003FF00      ; Address of Module Base Address Reg.
MODBASE        EQU $FFF00000      ; Default Module Base address value
CSAM0          EQU $40                  ; chip select 0 mask reg
CSBAR0        EQU $44                  ; chip select 0 base reg
CSAM1          EQU $48                  ; chip select 1 mask reg
CSBAR1        EQU $4C                  ; chip select 1 base reg
CSAM2          EQU $50                  ; chip select 2 mask reg
CSBAR2        EQU $54                  ; chip select 2 base reg
CSAM3          EQU $58                  ; chip select 3 mask reg
CSBAR3        EQU $5C                  ; chip select 3 base reg   
ROM_START   EQU $00000000        ; ROM Starting Address
ROM_SIZE    EQU $0007FF00      ; ROM Size 512KB
RAM_START   EQU $40000000        ; RAM Starting Address
RAM_SIZE    EQU $000FFF00      ; RAM Size 1MB
IO_1_START  EQU $80000000        ; IO1 Starting Address
IO_1_SIZE   EQU $00F9FF00      ; IO1 Size
IO_2_START  EQU $C0000000        ; IO2 Starting Address
IO_2_SIZE   EQU $00F9FF00      ; IO2 Size


    SECTION __CODE

__cstart
__START  

.even


; =======================================================================
; Disable interrupts
; =======================================================================
    MOVE.W  #$2700,SR                         ; disable interrupts    
   
; =======================================================================
; MBAR setup
; =======================================================================
    MOVE.L  #$7,d0
    MOVEC   d0,DFC                            ; source function code = CPU space
    MOVE.L  #MODBASE+$101,d0                  ; MBAR $FFF00000 + AS7=1 (UM Addendum) + V=1
    MOVES.L d0,BAR

    MOVEA.L  #MODBASE,a5                       ; SIM40 base

; =======================================================================
; Configure CS0 = ROM, 512 KB, 16 bit, external DACK
; =======================================================================
       MOVE.L  #ROM_SIZE+$3,(MODBASE+CSAM0)       ; CSOR0
       MOVE.L  #ROM_START+$9,(MODBASE+CSBAR0)   ; CSBAR0
   
; =======================================================================
; Configure CS1 = RAM, $40000000, 4 MB, 16 bit, external DACK
; =======================================================================
    MOVE.L  #RAM_SIZE+$3,(MODBASE+CSAM1)     ; CSOR1
    MOVE.L  #RAM_START+$1,(MODBASE+CSBAR1)   ; CSBAR1

; =======================================================================
; Configure CS2 = I/O, $80000000, 16 MB, 8 bit, external DACK
; =======================================================================
    MOVE.L  #IO_1_SIZE+$3,(MODBASE+CSAM2)    ; CSOR2
    MOVE.L  #IO_1_START+$1,(MODBASE+CSBAR2)  ; CSBAR2

; =======================================================================
; Configure CS3 = I/O, $C0000000, 16 MB, 8 bit, external DACK
; =======================================================================
    MOVE.L  #IO_2_SIZE+$3,(MODBASE+CSAM3)    ; CSOR3
    MOVE.L  #IO_2_START+$1,(MODBASE+CSBAR3)  ; CSBAR3
   
; =======================================================================
; Configure Clock - External 25MHz with PLL on
; =======================================================================
    MOVE.W  #$7F00,4(a5)              
pll_lock:
    MOVE.W  4(a5),d0
    BTST    #3,d0
    BEQ     pll_lock

; =======================================================================
; Disable watchdogs
; =======================================================================  
    MOVE.B  #$00,($40,a5)               ; software watchdog off
    MOVE.W  ($6,a5),d0
    ANDI.W  #$FF7F,d0
    MOVE.W  d0,($6,a5)                  ; bus monitor off

 

I was hoping that somebody else knew SIM40, because I don't. My CPU32 experience is with a few dozen SIM (probably equal amounts of 68331 and 68332). Lack of direct knowledge is not going to stop me from posting. Because Internet.

Here's some free advice from a random guy ..........

1. I *think* that the MOVE instruction may need to be a single word. The example in MC68340UM Section 4.4.3 page 4-39, actually every example or instance that I've ever seen, uses MOVE.L (Atable)+,(Aregister)+ in a loop. Something about flushing the CPU prefetch and Bus Interface after switching. Truth is, I've long since forgotten the rationale. Anyway, I would politely suggest copying their example code, at least as a start.
2. I do not understand the #MODBASE+$101, as I was expecting #MODBASE+$1 in the setting of MBAR. Motorola, in the example of MC68340UM Section 4.4.3 page 4-39, also uses $1 instead $101. Just something to look at.

I repeat that I've never experienced your chip's SIM40. But, if I were making a new product using that chip, my instincts would guide me through these two ideas.

 

Hi Thanks for the reply, "random guy"!

I will try the MOVE.L (Atable)+,(Aregister)+ suggestion. I have in the past, but since I haven't got anywhere for the last few weeks, months actually, I will give it a shot. "Something about flushing the CPU prefetch and Bus Interface after switching." that makes a lot of sense to me.

As for the #MODBASE+$101 change from #MODBASE+$1 , it's from the user manual addendum Rev 1 -
"On page 4-21, for the second code sequence, change the "MOVE.L #$FFFFF001,D0" to "MOVE.L
#$FFFFF101,D0". This sets AS7 in the MBAR to prevent the address decode for the internal 4K register
block from responding to CPU space accesses. In particular, it prevents the register block decode of
$FFFFFxxx from interfering with IACK cycles (address $FFFFFFFx), and possibly corrupting the vector
number returned. Normal interrupt acknowledge operation for the internal modules is not affected by this
change."

Thank you again!

 

I also found this in the User manual addendum Rev 1 -

29. SIM40 Example Code
On page 4-39 the code line "MOVE.L #MODBASE+1,D0" should read "MOVE.L #MODBASE+$101,D0" -
see notes above for page 4-21. The fourth line from the bottom should read "MOVEQ #7,D0".

 

OK, still locks up at the CS0 chip select. Here's the code I used, right after setting the MBR and clock.

***************************************************************************
* Now, set up Address masks and base addresses for the chip selects:
        
        LEA CSAM0+MODBASE,A0         ; Point to CS0 addr. mask location.
        MOVEQ #7,D0                     ; Set up a loop counter.
        LEA CSAM0$,A1                     ; Point to addr mask memory location.
LOOP MOVE.L (A1)+,(A0)+
        DBRA D0,LOOP

and the table:

***************************************************************************
* Data table for chip select initialization
***************************************************************************
CSAM0$ DC.L     ROM_SIZE+$03
CSBAR0$ DC.L     ROM_START+$09
CSAM1$ DC.L     RAM_SIZE+$03
CSBAR1$ DC.L     RAM_START+$01
CSAM2$ DC.L     IO_1_SIZE+$03
CSBAR2$ DC.L     IO_1_START+$01
CSAM3$ DC.L     IO_2_SIZE+$03
CSBAR3$ DC.L     IO_2_START+$01
***************************************************************************

I also check the output listing for the startup.asm and the values assigned are correct, e.g. CSAM0$ DC.L ROM_SIZE+$03 is CSAM0$ DC.L $0007FF03

Thanks for the idea tho, much appreciated!

 

Hi there. Just one other thing.

Can you confirm that you are satisfied with your "MODBASE EQU $FFF00000" definition?

1. Their documentation uses $FFFFF000.
2. They have an application note, AN453, which demonstrates some serial port stuff, and they use $FFFFF000 there as well. Their code in Appendix B refers to PortA two different ways, once using the "MODBASE+11" approach, and also using the hard-coded FFFFF011. (The AN453 author chose to name the SIM Base as "SIMBA" instead of "MODBASE" but its the same thing.)
3. In post #3, talking about MODBASE+$101, you copy/paste their text of item 26 of the addendum. They are using the literal itself, such as #$FFFFF101 versus #$FFFFF001 to talk about using MODBASE in the original text of 4-21. This is a "neat" aliasing idea that they came up with in order to deal with something outside of this discussion, but the SIM40 peripheral itself is still on the FFFFF000 4K page.
4. Your code is MOVE.L #MODBASE+$101,d0 which is MOVE.L #$FFF00101,d0

The 68332, for example, has SIM, QSM, and TPU peripherals at FFFA00, FFFC00, and FFFE00, respectively. Doesn't matter what they are. The point is, in its 24-bit addressing, the peripherals are at FFFx00. I expected to see them in the 68340 at FFFx00 in a 24-bit scheme, or FFFFFx00 in a 32-bit scheme. For example, the 68340 serial port module is at FFFFF700. Notice the upper 8 bits (which are ignored in 68332), then the "FFF" that gets to the 4K page, and then the 700 (in the case of 68340 SERIAL). Your FFF00000 MODBASE definition puts the peripherals on the "F00" page instead of the "FFF" one.

A test would be to write something to where you think SYNCR is (MODBASE+4), and see if the clock speed changes.

This does not, however, explain the behavior change due to writing a single bit of 0 or 1. I dunno, I just cannot figure out how your "MODBASE+44" is getting to CSBAR0 at FFFFF044.

So anyway, yeah, this .............

 

Hey There,

I assure you that you know better than me in regards to these CPUs!

Unfortunately, trying the MBAR value of $FFFFF000 still does not work on my side. It's my understanding that the $FFFFF000 value is the default value of the MBAR register out of reset, however, pretty much any value can be written (following the rules) to move around the 4K SIM block in the memory map. To be safe, I will be using $FFFFF000 anyway moving forward (hopefully.)

Also, I double checked that the SIM40 mapping is working by changing the values in the SYNCR and observing the Clock Out frequency changing. In the code, I also have to test that the PLL is locked before moving on, and that test does pass.

I'm wondering if the issue is related to the start address of the code, (to be clear, I have tried other start addresses and same result). In my code, the instructions start at $400 (reset vector points to $400), but most every example I have found start at $60000 or some other higher value.

I have heard so much stuff that it's confusing to me. I have heard that the CS0 can't be enabled while the Global Chip select is active (nothing in the documentation states this, in fact, the documents imply the opposite), I have also heard that I have to copy the CS0 enable code from ROM to RAM and execute it from there because the Global Select is active. That doesn't make sense to me since the Global Chip select is active and can access every external memory location, so running the code from RAM would make no difference, besides, RAM is on CS1 and you can't use any other CS while CS0 is not enabled.

As a side note, and maybe an insight, I completely bypassed the Chip Select logic and use the address lines to decode the RAM, ROM, etc. The idea was since the chip selects are not being used to enable the memory device, any glitch that may happen due to the CS0 being enabled would not cause an issue. Guess what, still locks up exactly when I set that V flag in the CS0 resister.

In previous versions of the board, I didn't use the PPL and thought maybe the issue was some silicon based issue related to it. Later versions use the PPL and still no difference in regards to the lock up. I chose the MC68340 for a few reasons, but the main one is that is has DMA and individual DMA handshaking signals. I'm open to using other CPUs in the family if they have similar DMA capabilities - I rather not tho, since I have a tray of these MC68340's.

Getting back to the MODBASE question, I think it's just my compiler. Seems like different assemblers/compilers have their own syntax (I am using the Crossware 680X0 C compiler and assembler), but the startup listing shows that is is being written in one shot.

 =======================================================================
  331                                   ; MBAR setup
  332                                   ; =======================================================================
  333 00000004 203C00000007                       MOVE.L    #$7,d0
  334 0000000A 4E7B0001                           MOVEC     d0,DFC            ; source function code = CPU space
  335 0000000E 203CFFFFF101                       MOVE.L    #MODBASE+$101,d0  ; MBAR $FFFFF000 + AS7=1 (UM Addendum) + V=1
  336 00000014 0EB908000003FF00                   MOVES.L   d0,BAR
  337
  338 0000001C 2A7CFFFFF000                       MOVEA.L   #MODBASE,a5       ; SIM40 base

Thanks again for your help and input, its all appreciated. I've heard the hardest part of the MC68340 is the initial configuration, yet, there's not much out there discussing it.

Best Regards!

 

Hi All,

Just wanted to say thanks for the assistance. I was able to get the CS0 working finally.

Basically, the issue was my ROM circuitry was generating DSACK1, which is correct for a 16 bit ROM, but was creating a timing glitch when the CS0 was being enabled. I set the CS0 values to use internal DSACK for the ROM and disabled the external DSACK that was being generates when the ROM was being selected. The other CS enabled devices use external DTACK and work correctly, including the RAM.

Here is what the project looks like along with a Debug Display that I used for debugging.

The project is a rack mount guitar effects processor.

Thanks again for all who assisted me!

Best Regards, Paul.

 

That's some retro computing hardware there. I loved the old 68000 series of processors.

 

That's some retro computing hardware there.

I'm stuck in the 80's lol! Yes, they're great CPUs!

 

I thought that assembler code looked familiar, turns out its more or less the same as my old fave 68030.