This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C164, CA step CAN

Dear Sirs, Mr. Coppi!

...I use the CAN-Module of a CA-step. Because everything was fine using the Board, I burned it without looking at the errata sheed...I was surprised at the result!
Now I want to please You help me avoid another mistake.

The behavior can be avoided if a message object is not updated by software when a
transmission of the corresponding message object is pending (TXRQ element is set)
and the CAN module is active (INIT = 0).


Does that mean, if I would disable the CAN module each time I change something (data) in an object and enable it after that everything will be o.K.?

The nodes in the CAN system ignore the remote frame with the identifier=0 and no
data frame is triggered by this remote frame.


Is this another or additional possibility?
Is there a way to disable only the identifier '0'?

I'm not so sure if I did understand the errata well, so please don't wonder about this questions.

Do You know about a distributor who could have a flash device of the C164? (It's really expensive for me to burn them so often and this could prevent al least wrong startup configurations other mistakes which are not step-specific?!)

Thanks a lot for helping me
hannes

P.S. why differs the behaviour using the RAM of the Board instead of OTP??

  • Hello Hannes,
    if you chip works fine in debug (RAM) mode and not in OTP, it is unlikely you have problems due to what described into Errata Sheet. (My personal opinion...)
    Please describe what is happening on your system, maybe it is just a startup or mapping problem.

  • Thanks for reply!

    I will try to describe the behaviour completely...
    ..if I use RAM everything is fine, if I use flash (on board) or start from OTP, some Messages will be send for example like ID= 374 data length= 15 contents is 0xFF or 0xDF.
    Some are Remote transmission requests, some normal messages. The Message that should be send for testing if the CAN works, is never transmitted.
    I think You are right again, the configured startup configuration (e.g. clcfg=4(XTAL*5), clckout enabled) seems to be ignored, and the Port0 seems to be used for initialising.
    I saw, I had forgotten that the internal Rom was mapped to segment1- this version is burned now! The not mapped version (in flash) behaves like the OTP version too.

    I must admit, i don't know exactly what the mapping means- I think, Segment1 is normal OTP space, and the programm should work fine also in that area?!



    The external configuration is: EA =high, RD =high, ALE =0, the RESET will be high- delayed by a capacitor.

    I hope You are not shocked at me!
    ( ...I am sometimes because I seem to do wrong everything that is possible)

    Best regards hannes

  • Ciao Hannes,
    let's start from this: you have an application that
    - works correctly when placed in RAM.
    - stops working when flashed.
    Program behaves like a RAM segment is misplaced. (Variables are mapped in a place where no RAM exist).
    You may have several problems:
    1) startup file for Flash is different from startup file for RAM and your Flash startup file contains wrong settings.
    2) memory map for Flash is different from memory map for RAM and your Flash mapping contains wrong settings.

    Regarding 1): do you have a project (any project) that works correctly when flashed on the same hardware?
    If YES, just take the startup file from that project and check its settings against the startup you are actually using.
    If NO, check carefully the startup to understand if you have any wrong register setting.

    Regarding 2): check the MAP file, data sections must be located in RAM, const and code sections must be located in ROM.
    Check CAREFULLY that your sections reside INTO existing space (maybe you have some data section located into NOWHERE, outside of existing RAM).

    NEVER map ROM to Segment 1 when you run with EA = 1 (unless you know what you are doing).
    Mapping ROM to SEGMENT 1 means that the ROM is moved from address 0 to another address over 64K. This is useful when you want to use an external Flash located at 0 but you want still to use the internal ROM.
    If you leave the ROM enabled, you cannot see the external Flash at 0 because the internal ROM is mapped at the same addresses and it has precedence over external bus.
    Moving to a different location will allow you to see the External Flash at 0.
    Think about this: you are running a program from internal ROM located at 0, let's say you are executing at address 0x0200 and you move the ROM away from 0; you may experience some problem, because the ROM will no more be there (at 0) and microcontroller will fetch instructions from NOWHERE...
    So, don't try to move the ROM until you are sure about what you are doing.

    About startup clock frequency: I cannot check it here because I don't have the manuals with me, I will check ASAP and let you know.

    Ciao
    Bruno

  • Dear Mr. Coppi!
    I gave up to figure out the Problems (e.g. the clock works correct only with jumperconfiguration, allthough i did configure it by software....). I want to please You to write Your opinion to that: i will take the CAN Project i wrote once and burn it. The difference is the use of CA-step instead of DA-step. I think it should work?
    To be sure i will mask out the eleventh bit of the ID arbitration register, so all ID's must be higher than, or equal 0x400 for beeing accepted. By that way i hope to prevent the CAN module for sending request messages with ID '0'(?!)
    I would do because i read this in errata sheet:



    Workarounds:
    • The behavior can be avoided if a message object is not updated by software when a
    transmission of the corresponding message object is pending (TXRQ element is set)
    and the CAN module is active (INIT = 0). If a re-transmission of a message (e.g. after
    lost arbitration or after the occurrence of an error frame) needs to be cancelled, the
    TXRQ element should be cleared by software as soon as NEWDAT is reset from the
    CAN module.

    • The nodes in the CAN system ignore the remote frame with the identifier=0 and no
    data frame is triggered by this remote frame.


    Would be nice if You could help me by that decision (it's really expensive by the time).

    Like i wrote before i wonder about the difference between RAM and Flash memory. I took a look at the schematic of the board and the memories are connected in parallel. So i can't really explain how this could be different. Could it be a reason of waitstates or something like that? (I think the startup of Ram is the same of Flash?) Do You know something? All that seems to me like kind of mystic.
    Do You know literarure, where is written more about the map file, i think i have to learn about these things to be more sure knowing what i'm doing! Sorry, that i reacted so late to your reply- i have to learn for some tests at the moment.

    Thank You!
    Best regards hannes

  • Hello again!
    I'm sorry, I think i was wrong with that preventing the CAN from accepting ID '0' by mask out bit 11 of abritation register ( i meant global mask)...
    But what is the global mask good for? If bits in global mask are set, they will be masked with incoming messages (all are accepted first and then selected by the object ID). If a '0' bit in global mask will ignore respective incomming bits like "don't care", but after that they will nevertheless be compared with object ID. So why global mask? Is it just to prevent the CAN controller for comparing incoming ID's with Object ID's by filtering incoming messages first?
    And how have i to understand the errata? If there is no ID=0 this CAN-error should never happen? But it does!?
    hannes

  • Ciao Hannes,
    you are mixing a lot of confused ideas...

    1) Your reference source should ever be THE MANUALS - Keil for Software, Infineon for Hardware.
    2) I repeat, you told me that you have an application that works when placed in RAM, so FORGET the errata sheet (temporarily..), if your application is working in RAM, it is UNLIKELY you are running into errata sheet problems!

    About Mapping: basically any microcontroller has two main memory spaces: ROM and RAM; ROM will contain the NONVOLATILE program
    part (CODE and CONSTants), while RAM will contain the DATA.
    Going into further detail, each of these spaces can be divided into logical sections, each of them having some characteristics, defined by the "environment", where for "environment" i mean the Compiler Architecture and the Microcontroller Architecture and Instruction Set.
    During Compiler Specification phase, the Compiler writer (Mr. Keil) studies the Microcontroller Instruction Set and decides how to best use it to obtain the "optimum" code during compile.
    In case of C164, the ROM memory area is split into CODE and CONST classes, then the CODE class is further divided into NCODE (NEAR CODE) and FCODE (FAR CODE).
    NEAR CODE means that code uses NEAR CALLS and NEAR RETURN of C164 Instruction Set, these are instructions that use only 16bit displacement and thus works only INSIDE of the SAME 64K memory segment.
    If you need to call or jump to code contained into a different 64K segment, you must use FAR CODE, using FAR CALLS and FAR RETURN, which are instructions that use 24 bit displacement.
    This same situation occurs for CONST classes: NCONST is a class the compiler accesses by means of a single preset DPP register, so it can be at most 16K wide.
    If you need more CONSTants, you must place them in FCONST or HCONST sections.
    The compiler generates different instruction sequences to access the different sections, this way you can choose to place some CONSTants into a small section that can be accessed very quicly and some other in a larger section that can be accessed slower.
    If you are "crazy" enough (or if you know what you do, in some special case...), you can decide by yourself where to place each piece of code you write, like

    void far MyFarFunction (void) ....
    
    or
    
    unsigned int huge MyHugeVariable;
    
    otherwise Keil provides some preset memory models, like SMALL, MEDIUM, LARGE and so on.
    Each memory model defines what memory classes the compiler will use, for instance the SMALL memory model will generate NEAR CODE (NCODE), NEAR CONSTant (NCONST) and NEAR DATA (NDATA) classes, while the LARGE model will generate FAR CODE and so on...
    There are some exceptions, but I think that my explanation is near enough to reality to give you a 'basic' knowledge, please study the Keil manuals to get a more precise
    description.

    For MAPPING and MAP file, please start here.
    http://www.keil.com/support/man/docs/l166/l166_memory.htm

    Back to your application: when you debug a program in RAM, you place all sections (CODE, CONST, DATA) in RAM and this is an easy environment, you can mix everything and don't worry about non writeable memory spaces.
    When you burn the program in ROM, you must redefine the MAPPING, this means you must precisely tell the linker where to put each memory class, paying attention to WRITEABLE and NON WRITEABLE memory.
    If you place a DATA section into the ROM, you won't ever be able to WRITE to this section and your program will produce unpredictable results (C164 will go in the forest...)
    When you burn a program in ROM, you must follow these steps:

    1) decide the PHYSICAL C164 MEMORY LAYOUT - This means define what memory you will have in your system and where is placed into the address space.
    When you debug a program in RAM, the RAM chip select is ENABLED by the monitor in a window starting at address 0x000000; this MUST be changed when you place a program in ROM, the RAM cannot be present at 0x000000.

    2) Modify the STARTUP FILE to properly enable the memory (Chip Selects) in order to obtain the choosen layout at RunTime.

    3) Properly LOCATE the memory SECTIONS and CLASSES at the correct RAM and ROM addresses.
    You can use the simulator to check your configuration and to test if this will work before you burn an OTP.

    Ciao
    Bruno

  • Hello again,
    about C164 clock: step CA was still using the Port 0 configuration for clock multiplication setup.
    The software method described in the new manual is valid since step DA.
    For step DA I modified my startup code this way to change PLL multiplication factor.

    ?C_RESET        PROC TASK C_STARTUP INTNO RESET = 0
    ?C_STARTUP:     LABEL   Model
    
    
    $IF (WATCHDOG = 0)
                    DISWDT                  ; Disable watchdog timer
    $ENDIF
    
    ; BC MODIFICATION - BEGIN PLL CLOCK SETUP
    
                    MOV     R15,#09B00H
                    MOV     RSTCON,R15
    
                    EXTR    #1
                    MOV     SYSCON2,#00500H
    
                    EXTR    #1
                    MOV     SYSCON2,#00400H
    
    ; BC MODIFICATION - END
    
    BCON0L          SET     (_MTTC0 << 5) OR (_RWDC0 << 4)
    BCON0L          SET     BCON0L OR ((NOT _MCTC0) AND 0FH)
    BCON0L          SET     BCON0L AND (NOT (_RDYEN0 << 3))
    BCON0L          SET     BCON0L OR (_RDY_AS0 << 3)
    
    

  • Hello!
    ..i read about Memory Organisation in manual: internal ROM area is located in: 0x00 to 0x7FFF. That means that section is only for reading and Program execution!? The sfr and RAM area is located in 0xF000 to 0xFFFF, where writing and reading is allowed, i think.?
    Is this correct: if i want to check the real behaviour i have to configure the memory map in simulator like this- and let run the program?

    Would be nice, You could answer again!
    Best regards hannes

  • ...and that is the Memory map of the map file:


    MEMORY MAP OF MODULE: ARNE2-270205_CA (HIWI_CAN)


    START STOP LENGTH TYPE RTYP ALIGN TGR GRP COMB CLASS SECTION NAME
    =====================================================================================
    000000H 000003H 000004H --- --- --- --- --- --- * INTVECTOR TABLE *
    000004H 000005H 000002H XDATA REL WORD --- --- GLOB --- ?C_INITSEC
    000008H 00000BH 000004H --- --- --- --- --- --- * RESERVED MEMORY *
    00000CH 000011H 000006H CONST ABS WORD --- --- PRIV --- ?C_CLRMEMSEC
    000088H 00008BH 000004H --- --- --- --- --- --- * INTVECTOR TABLE *
    000090H 000093H 000004H --- --- --- --- --- --- * INTVECTOR TABLE *
    0000ACH 0000AFH 000004H --- --- --- --- --- --- * RESERVED MEMORY *
    000100H 000103H 000004H --- --- --- --- --- --- * INTVECTOR TABLE *
    000104H 0001C1H 0000BEH CODE REL WORD --- --- PRIV ICODE ?C_STARTUP_CODE
    0001C2H 00049BH 0002DAH CODE REL WORD --- --- PUBL NCODE ?PR?HIWI_CAN
    00E000H 00E1FFH 000200H DATA REL WORD --- --- PUBL NDATA ?C_USERSTACK
    00E200H 00E20FH 000010H DATA REL WORD --- --- PUBL NDATA0 ?ND0?HIWI_CAN
    00FB00H 00FBFFH 000100H --- --- --- --- --- --- * SYSTEM STACK *
    00FC00H 00FC1FH 000020H DATA --- BYTE --- --- --- *REG* ?C_MAINREGISTERS

    ...the Target Classes, defined in Keil is:
    ICODE (0x0-0x7FFF), NCODE (0x0-0x7FFF), NCONST (0x0-0x7FFF),
    NDATA (0xE000-0xE7FF, 0xF600-0xFDFF), NDATA0 (0xE000-0xE7FF, 0xF600-0xFDFF),
    option is 'using Memory Layout from target dialog'

    Probably i'm wrong, but the DATA section should start at 0xF000 and end at maximum 0xFFFF???? (User manual v3.1,[3-2],line 2). How is it to define those sections, i used what i've got.

    If all this gets on Your nerves, ignore it!

    hannes

  • ...tihs is the MAP contents of µVision debugger:

    MAP
    0x00000000 - 0x00000003 exec read
    0x00000004 - 0x00000007 read write
    0x00000008 - 0x0000000B exec read write
    0x0000000C - 0x00000011 read
    0x00000012 - 0x00000087 exec read write
    0x00000088 - 0x0000008B exec read
    0x0000008C - 0x0000009F exec read write
    0x000000A0 - 0x000000A3 exec read
    0x000000A4 - 0x000000AF exec read write
    0x000000B0 - 0x000005C9 exec read
    0x000005CA - 0x0000DFFF exec read write
    0x0000E000 - 0x0000E207 read write
    0x0000E208 - 0x0000FFFF exec read write

    Should write access be enabled benath address 0xF000?

    Bye

  • Hello Hannes,
    please try to better read the Manuals and the Datasheets; the C164, before step DA, has only 2K of RAM, located F600-FDFF. STOP.
    If you try to allocate segments in the space E000-E7FF, they are allocated into nowhere.
    Area F000-FFFF is the address area left by C164 designers to be internally used for Register and RAM, but this does not mean that it is ALL used; some registers are F000-F1FF, some others are FE00-FFFF; on some C16x derivatives, there is internal RAM from F200 to FDFF, on C164 is just 2K F600 to FDFF.

  • Dear Mr.Coppi-it's me again..
    Sorry, i became a little lazy knowing You are there kind of a speaking/writing book...
    but also did not think and know about the things that were done by KEIL ide automaticly case-tool-like...

    I looked at the manual v1.00 ( because CA-step is indexed by 8EM:
    The descriptions in this manual refer to the following derivatives of the C164-class:
    l C164CI-8EM Version with 64 KByte on-chip OTP memory
    ...correct??
    Following given addressranges i found:
    0x0000-0x8000 :lower 32kB OTP
    0xEF00-0xEFFF :CAN
    !!! is this wrong? You wrote:If you try to allocate segments in the space E000-E7FF, they are allocated into nowhere.!!!
    0xF000-0xF1FF :esfr
    0xFE00-0xFFFF :sfr
    0xF600-0xFDFF :RAM
    0xE000-0xF000 :XRAM + CAN !!!!!same question as above!!!!!!!!!

    (Does there exist exact tables of Memory organization for all the Steps?)

    These values i wrote into the Memory Map and tested. Programm "crashed" (error message appeared), because indirect addressed Memory at address 0xE200 was accessed.

    Looking at the device database the Memory is defined at these addresses:CPU=IRAM(0xF600-0xFDFF) XRAM(0xE000-0xE7FF) CLOCK(20000000) IROM (0-0xFFFF) ICAN(0xE800-0xEFFF) MOD167

    I could define a new C164CI_CA e.g. to avoid the wrong accesses, i think???! I'm sorry, but don't really know where to find the exact Memoryorganization of CA step. Please could You help again?
    hannes

  • I don't know anything about the C164 but for the C167, I had to enable the XRAM before I used it,

          MOV   XPERCON,#0403H    ; Enable CAN 1 and CAN 2 Xbus peripherals
    	                          ; Enable XRAM 2 KByte memory
    	                          ; Disable XRAM 6 KByte memory
          NOP
          NOP
    
          MOV   SYSCON,#8184H     ; Stack size = 512 words
                                  ; Internal rom starts at 00'0000
                                  ; Segmentation enabled
                                  ; Internal rom disabled
                                  ; BHE pin enabled
                                  ; Clock out pin enabled
                                  ; WR is write low, BHE is write high
                                  ; Xbus peripherals are enabled
                                  ; Xbus accesses are not visible on external bus
                                  ; Xbus peripherals not accessable on external bus

  • Dear Mr. Coppi!
    I changed a copy of the C164CI in the Data Base. Now it works in Flash too!! Sorry because my Questions were thoughtless- i'm a bit stressed at the time and was somewhere else...nevertheless i feel like asking You again to be sure if it's right, before i burn it.

    The Memory, i allocated in the Data Base, is this:

    0x0000-0xFFFF := internal ROM
    0xF600-0xFDFF := internal RAM
    0xE800-0xEFFF := CAN area

    no XRAM!!

    I wondered, because in every UM i found XRAM at E000-F000 (e.g.at System Memory Map)!?

    Would be nice if You answer me!?

    hannes

  • Hi Brad,
    the C164 is older than other C16x derivatives so the XPERCON register is not present, you just have a more generic bit XPEN in the SYSCON register used to enable/disable XRAM (when present) and CAN.