mc9sdp512 ucontroller R/W CF card question

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

mc9sdp512 ucontroller R/W CF card question

1,404 Views
Ebird
Contributor I

Hi,

I am a newbie of mc9sdp512 ucontroller. I am digging a CF file issue for my company and I had a hard time to understand some legacy asm code.

 

The following is the code:

 

_gfOpen::
    pshx
    tfr    d,x                ;file name pointer is in accd
    lda    5,sp            ;get drive num and operation type
    ldb    #14
        swi
        clra
    pulx
        rts

 

What I don't understand is that after load 14 to accumulator b and call software interrupt. The file on CF card is open "magically". How it is opened I don't know. Here in the vector table, swi is defined as this:

 

word swiHndl        ;$fff6 SWI

 

this is swiHndl:

swiHndl:
        tsx
        xgdx                    ;accd = sp of current stack
        jmp     jOS_call    ;do OS_call    

 

And jOS_call:

jOS_call::        jmp    0        ;operating system call

 

Anyone can hlep me figure how the file on the CF card is opened?

Labels (1)
0 Kudos
9 Replies

673 Views
kef
Specialist I

Hm, jmp 0? Either it is a jump to what contents of PORTAB register points to, or maybe some resorces remapping is done using INITRM, INITEE, INITRG registers.

0 Kudos

673 Views
Ebird
Contributor I

Hi Kef,

Thanks for the reply. The snippet in my question is a combination of asm code I grabbed from different place to make them make sense. However I just don't understand what makes them meanningful. I found one more cacro def in one of header file like this:

 

.macro fileOpen
    ldab  #_FLASH_OPEN    ;file open function call
    swi            ;result code/filenumber in accb, x:y = file size
    .endmacro

swi is the same as what I posted

 

Still does not make sense.

0 Kudos

673 Views
kef
Specialist I

I think OS routine is expected at address 0. It seems OS function number is passed to OS routine in register B. This makes sense.

Do you wonder how pointer to file name is passed to OS routine? Yes, I also don't see how it is done. Pointer to file name seems to be passed to _gfOpen in reg D, then it is transferred to reg X and finally SWI call is made. But swiHndl overwrites reg X with SP, so I don't know how _gfOpen is passing file name to OS routine.

0 Kudos

673 Views
Ebird
Contributor I

The file name is in reg x. At the beginning of gfOpen, pshx save it in memory and then tfr d, x will copy it to d. Eventually, when the file is opened, the size of the opened file is in y. What I don't understand is this:

 

ldb    #_FLASH_OPEN ( _FLASH_OPEN = 14)

 

why put a int 14 to b before swi? and how software int can do file operation like this?

 

And about address 0, is it address of register PORTA? I got this line from the Freescale spec 9SDP256BDGV2:

 

Address Name Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Bit 0
$0000 PORTA
Read:
Bit 7 6 5 4 3 2 1 Bit 0

0 Kudos

673 Views
kef
Specialist I
  • The file name is in reg x. At the beginning of gfOpen, pshx save it in memory and then tfr d, x will copy it to d. Eventually, when the file is opened, the size of the opened file is in y. What I don't understand is this:

 

Oh yes, swi handler can access file name pointer pushed previously to the stack.  It is transferred from d to x, but later x is destroyed doing tsx.

 

 

  • ldb    #_FLASH_OPEN ( _FLASH_OPEN = 14)
  •  why put a int 14 to b before swi? and how software int can do file operation like this?

 

Why not? SWI doesn't change any CPU register. What you load to any CPU register before SWI, everything will be passed to SWI handler.

 

 

  • And about address 0, is it address of register PORTA? I got this line from the Freescale spec 9SDP256BDGV2:

Yes, but S12D allows register, EEPROM and RAM remapping. So your legacy code could move registers block away from 0 and map here RAM or EEPROM with some code.

 

0 Kudos

673 Views
Ebird
Contributor I

Based on your reply, I understand this is what happened:

 

swi actually does the magic to open file, and the integer #_FLASH_OPEN is passed to swi to ask it to open file.

 

 

The bits in reg x: I have no clue how the file name can survive after tsx

0 Kudos

673 Views
kef
Specialist I

File name pointer in X doesn't survive, but it is pushed to the stack before SWI. So inside SWI handler (and in routine at 0) file name pointer is available on the stack at SP+9.

0 Kudos

673 Views
Ebird
Contributor I

I had that thought while we talk back and forth. However I have no idea how you figure out reg x is pushed to sp+9. I check the chip spec and it says x will be pushed to sp-4 and sp-5.

 

This is what I got from spec:

 

Table 5-5. Stacking Order on Entry to Interrupts
Memory Location CPU Registers
SP PCL
SP–1 PCH
SP–2 IYL
SP–3 IYH
SP–4 IXL
SP–5 IXH
SP–6 ACCA
SP–7 ACCB
SP–8 CCR

 

Could you tell me how you get the mem location of SP+9 as where reg x is pushed? Thanks!

0 Kudos

673 Views
kef
Specialist I

Oh, my mistake. Comment in gfOpen states that file name pointer is in D, and I thought it was in X and pushed to the stack. And contents of X, that was pshx'ed in gfOpen is available in the SWI handler at SP+9.  Your list of stacked registers confirms that. 2bytes X + 2 bytes Y + A + B + CCR + 2 bytes PC = 9 bytes.

0 Kudos