FCLKDIV in S12XET256

[michaelhuslig]

I haven't been able to get a commercial BDM working on my board, so I have been modifying a personal BDM I built years ago.  In general, I can read and write to the target.  However, I notice that after resetting the target, FCLKDIV reads as 0x90.  My BDM hasn't set it at that point.  Also I can change the value of FCLKDIV with the BDM, although the MSB remains set.  It is supposed to be write-once.  Any ideas?

Mike

[michaelhuslig]

Sorry for the late response.  I think my original problem was that the reset line from my BDM wasn't connected to the reset on the target board due to a flaky connector.  I think...

[michaelhuslig]

As a clarification, I tried a different target board.  FCLKDIV came up 0 on reset.  However, I could still change it once it was set.

Mike

[lama]

Hi,

it looks like missing info in the data sheet (tested and you are right).

Usually when the register is write once only then it is valid only for normal modes.

In special modes the register is rewritable.

(This is standard mistake of many users when they rewrite writeonce only bits which were already somewhere written (for example in some startup code) and everything is working during debugging but not working in real "normal" modes.

Best regards,

Ladislav

[michaelhuslig]

If FCLKDIV is 0x90 after reset, I don't know whether I can set it to the proper value when I finally get the end program running.  However, this value of 0x90 may be a fluke.  I noticed that after reset, FPROT is 0xE4 and EPROT is 0x84.  Since these values are supposed to be coming from FLASH, which is all 0xFFs, it looks like something is wrong with this particular chip.  I am using a second board which defaults FCLKDIV to 0 and xPROT to 0xFF.  But I am still having no luck with the commercial BDM in accessing the target using CW5.2.  Is there anything else which might explain the strange reset values in the first board?

About missing info in the data sheet, can you confirm that when using the BDM, if BDMGPR (BDM GPAGE register) is 0, any access using, for example, the READ_BYTE BDM hardware command and its 16-bit address maps into the full memory map using the uP's DIRECT, PPAGE, RPAGE, and EPAGE?

Mike

[michaelhuslig]

I spoke too soon.  Now the second board appears to have the same wrong initial values to FCLKDIV and xPROT.

Mike

[lama]

It is not possible to be FCLKDIV 0x90 after reset. Where is the point you check it? If you use some “code generator” like for example Processor Expert, then there are automatically inserted initialization procedures. If you check the code and “after reset” means I have just stopped at the first instruction of the main() then this is not “after reset”.
Have you tried to perform mass erase/unsecure procedure by means of your debug interface or some another program like Unsecure_12 from pemicro.com. If the chip has different values in the flash from 0xFF and/or defined values in the defined flash fields and registers after this procedure and power on reset differs from guaranteed by the datasheet then I can say yes the MCU is an issue.

BDMGPR….there are two approaches of the memory> local and global. Local uses RPAPE, PPAGE,… Global uses GPAGE. Which is used depends in the case of BDM on the bit BGAE setup. If BGAE is 1 then global access is enabled and global page address is written into this register.
(Global access assembler functions do not have connection to this GLDD, GSTD,…)
So, in the case I want to access LOCAL paged space  PPAGE_OFFSET then I disable/clear  BGAE (BDMGPR register) (HW BDM commands) bit and use PPAGE register with offset 8000-BFFF or RPAGE with offset 1000-1FFF or EPAGE and offset 0800-0BFF.
If I want to use global address then  set BGAE (BDMGPR register) and use GLOBAL address written to BDMGPR = 0x80 | global_page. Ofsset is 64k. If the BDMGPR is set to 0x80 then the space you can read is global address 00_0000 – 00_FFFF which contains (I suppose normal mode (exclude expanded mode)) only registers 00_0000_00_07FF

Hmmm, I think we slipped to BDM command and functionality. If you are not BDM developer and you only some development IDE with defined structure of communication then it has no meaning to go deeper into it because each developer creates his own communication structure, command usage, background SW implementation,……

For example in the CodeWarrior Memory window of the debugger I can visualize the same space by-
-    Setting PPAGE in the Register window to 0xFE and asking to visualize memory 0x8000’L in memory window.
-    Or directly asking to visualize global memory 0x7F8000’G in memory window
How it is done on background…I do not know.

May I see schematic of your board...important for me is MCU environment?

What OS you use and what commercial interface is not working?

Do you have CW 5.1 and W7 available for tests?

Best regards,

Ladislav