S12 / MagniV MicrocontrollersのトピックRe: mc9sdp512 ucontroller R/W CF card question

mc9sdp512 ucontroller R/W CF card question

Ebird — Thu, 19 Aug 2010 22:51:22 GMT

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?

Re: mc9sdp512 ucontroller R/W CF card question

kef — Thu, 19 Aug 2010 23:18:42 GMT

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.

Re: mc9sdp512 ucontroller R/W CF card question

Ebird — Thu, 19 Aug 2010 23:24:37 GMT

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.

Re: mc9sdp512 ucontroller R/W CF card question

kef — Fri, 20 Aug 2010 00:13:41 GMT

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.

Re: mc9sdp512 ucontroller R/W CF card question

Ebird — Fri, 20 Aug 2010 00:53:32 GMT

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

Re: mc9sdp512 ucontroller R/W CF card question

kef — Fri, 20 Aug 2010 01:26:21 GMT

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.

Re: mc9sdp512 ucontroller R/W CF card question

Ebird — Fri, 20 Aug 2010 01:45:26 GMT

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

Re: mc9sdp512 ucontroller R/W CF card question

kef — Fri, 20 Aug 2010 02:24:16 GMT

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.

Re: mc9sdp512 ucontroller R/W CF card question

Ebird — Fri, 20 Aug 2010 02:54:07 GMT

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!

Re: mc9sdp512 ucontroller R/W CF card question

kef — Fri, 20 Aug 2010 03:09:00 GMT

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.