This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TMS320F28379D: Memory map prevented reading a mapped hardware register.

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

Tool/software: Code Composer Studio

When debugging our LaunchXL-F2379D through the onboard XDS100we cannot see registers associated with a hardware peripheral, though the data pointers can be seen pointing to the correct addresses in memory to do so. This only occurs within implementations where we utilize CAN, and is isolated to this module as well. Similar operations on other peripherals like SCI and CPU Timers yields expected behavior. With the CAN register sets, however, not only are reads unavailable to us within the debugger view (seen in the picture below, reads to the pointer 'm_Reg' at the lowest level return an error), we also cannot seem to update the registers from compiled instruction sets as we watch them in real time from within the register window. As we make direct writes to the pointer 'm_Reg' mentioned above, the values are not reflected as they should be within the hardware registers. I have included our linker command file as well.

Attempting to look at the registers through our variable window is the best clue that we've been able to find so far. Expanding the data pointer which is meant to point at the register its wrapper class is named after tells us that the "memory map prevented reading address ... " though looking at the pointer itself, we see that it is indeed pointing at the location it is meant to. The CAN register section is separate from the other peripherals in location and function, so I think that we are missing some rule or statement that configures either the compiled code or the debugger to read them correctly.

The memory sections defined there map to the correct locations for this microprocessor, and our source code references those sections using "#pragma DATA_SECTION()". I have included the linker file and our register definition file, they are the default C2000Ware provided versions with some modifications made. I am not able to provide source code, but if there is any other forms of data that would be helpful then I am happy to provide them.

2837xD_FLASH_lnk_cpu1_cmd.txt
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
MEMORY
{
PAGE 0 : /* Program Memory */
/* Memory (RAM/FLASH) blocks can be moved to PAGE1 for data allocation */
/* BEGIN is used for the "boot to Flash" bootloader mode */
BEGIN : origin = 0x080000, length = 0x000002
RAMM0 : origin = 0x000122, length = 0x0002DE
RAMD0 : origin = 0x00B000, length = 0x000800
RAMLS0 : origin = 0x008000, length = 0x000800
RAMLS1 : origin = 0x008800, length = 0x000800
RAMLS2 : origin = 0x009000, length = 0x000800
RAMLS3 : origin = 0x009800, length = 0x000800
RAMLS4 : origin = 0x00A000, length = 0x000800
RAMGS14 : origin = 0x01A000, length = 0x001000 /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
RAMGS15 : origin = 0x01B000, length = 0x001000 /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
RESET : origin = 0x3FFFC0, length = 0x000002
/* Flash sectors */
FLASHA : origin = 0x080002, length = 0x001FFE /* on-chip Flash */
/*FLASHB : origin = 0x082000, length = 0x002000 /* on-chip Flash */
FLASHBC : origin = 0x082000, length = 0x004000 /* on-chip Flash */
FLASHD : origin = 0x086000, length = 0x002000 /* on-chip Flash */
/*FLASHE : origin = 0x088000, length = 0x008000 /* on-chip Flash */
/*FLASHF : origin = 0x090000, length = 0x008000 /* on-chip Flash */
/*FLASHG : origin = 0x098000, length = 0x008000 /* on-chip Flash */
/*FLASHH : origin = 0x0A0000, length = 0x008000 /* on-chip Flash */
/*FLASHI : origin = 0x0A8000, length = 0x008000 /* on-chip Flash */
FLASHEFGHIJ : origin = 0x088000, length = 0x030000 /* on-chip Flash */
/*FLASHK : origin = 0x0B8000, length = 0x002000 /* on-chip Flash */
/*FLASHL : origin = 0x0BA000, length = 0x002000 /* on-chip Flash */
/*FLASHM : origin = 0x0BC000, length = 0x002000 /* on-chip Flash */
FLASHKLMN : origin = 0x0B8000, length = 0x008000 /* on-chip Flash */
PAGE 1 : /* Data Memory */
/* Memory (RAM/FLASH) blocks can be moved to PAGE0 for program allocation */
BOOT_RSVD : origin = 0x000002, length = 0x000120 /* Part of M0, BOOT rom will use this for stack */
RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */
RAMD1 : origin = 0x00B800, length = 0x000800
RAMLS5 : origin = 0x00A800, length = 0x000800
RAMGS0 : origin = 0x00C000, length = 0x001000
RAMGS1 : origin = 0x00D000, length = 0x001000
RAMGS2 : origin = 0x00E000, length = 0x001000
RAMGS3 : origin = 0x00F000, length = 0x001000
RAMGS4 : origin = 0x010000, length = 0x001000
/*RAMGS5 : origin = 0x011000, length = 0x001000
RAMGS6 : origin = 0x012000, length = 0x001000
RAMGS7 : origin = 0x013000, length = 0x001000
RAMGS8 : origin = 0x014000, length = 0x001000*/
RAMGS56789 : origin = 0x011000, length = 0x005000
RAMGS10 : origin = 0x016000, length = 0x001000
RAMGS11 : origin = 0x017000, length = 0x001000
RAMGS12 : origin = 0x018000, length = 0x001000 /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
RAMGS13 : origin = 0x019000, length = 0x001000 /* Only Available on F28379D, F28377D, F28375D devices. Remove line on other devices. */
CPU2TOCPU1RAM : origin = 0x03F800, length = 0x000400
CPU1TOCPU2RAM : origin = 0x03FC00, length = 0x000400
ADCA_RESULT : origin = 0x000B00, length = 0x000020
ADCB_RESULT : origin = 0x000B20, length = 0x000020
ADCC_RESULT : origin = 0x000B40, length = 0x000020
ADCD_RESULT : origin = 0x000B60, length = 0x000020
ADCA : origin = 0x007400, length = 0x000080
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Can_Regs_hpp.txt
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/*
* Can_Regs.hpp
*
* Created on: Mar 19, 2020
* Author: chaparrojd
*/
#ifndef INCLUDE_F2837XD_CAN_IMPLEMENTATION_CAN_REGS_HPP_
#define INCLUDE_F2837XD_CAN_IMPLEMENTATION_CAN_REGS_HPP_
#include <Interface/Platform_Defines.hpp>
//#include <Source/Common/Regs/F2837xd_Can_Regs.hpp>
namespace f2837xd
{
namespace can
{
namespace impl
{
namespace regs
{
extern "C"
{
struct CAN_CTL_BITS
{
bp_16 Init:1; ///> 0 Initialization
bp_16 IE0:1; ///> 1 Interrupt line 0 Enable
bp_16 SIE:1; ///> 2 Status Change Interrupt Enable
bp_16 EIE:1; ///> 3 Error Interrupt Enable
bp_16 rsvd1:1; ///> 4 Reserved
bp_16 DAR:1; ///> 5 Disable Automatic Retransmission
bp_16 CCE:1; ///> 6 Configuration Change Enable
bp_16 Test:1; ///> 7 Test Mode Enable
bp_16 IDS:1; ///> 8 Interruption Debug Support Enable
bp_16 ABO:1; ///> 9 Auto-Bus-On Enable
bp_16 PMD:4; ///> 13:10 Parity on/off
bp_16 rsvd2:1; ///> 14 Reserved
bp_16 SWR:1; ///> 15 SW Reset Enable
bp_32 INITDBG:1; ///> 16 Debug Mode Status
bp_32 IE1:1; ///> 17 Interrupt line 1 Enable Disabled
bp_32 rsvd3:1; ///> 18 Reserved
bp_32 rsvd4:1; ///> 19 Reserved
bp_32 rsvd5:1; ///> 20 Reserved
bp_32 rsvd6:3; ///> 23:21 Reserved
bp_32 rsvd7:1; ///> 24 Reserved
bp_32 rsvd8:1; ///> 25 Reserved
bp_32 rsvd9:6; ///> 31:26 Reserved
};
union CAN_CTL_REG
{
bp_32 all;
struct CAN_CTL_BITS bit;
};
struct CAN_ES_BITS
{
bp_16 LEC:3; ///> 2:0 Last Error Code
bp_16 TxOk:1; ///> 3 Transmission status
bp_16 RxOk:1; ///> 4 Reception status
bp_16 EPass:1; ///> 5 Error Passive State
bp_16 EWarn:1; ///> 6 Warning State
bp_16 BOff:1; ///> 7 Bus-Off State
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Hello Jensen,

    This is a known issue. See the below thread:

    https://e2e.ti.com/support/tools/ccs/f/81/t/753701?tisearch=e2e-sitesearch&keymatch=%20user%3A388172

    What version of CCS are you using?

    Thanks

    ki

  • Ki said:
    What version of CCS are you using?

    And which C2000Ware version?

  • Jensen and I are both looking into this, he is on I think 9.0.1 CCS (I think, though Jensen would have to verify) and I'm using 9.3.0.00012, both have the same issue.   The C2000Ware version that I have is C2000Ware_3_01_00_00. 

  • There are are two fixes needed for this issue, one for CCS and one for C2000Ware (C2000Ware needs to be migrated for the CCS version with the fix). I checked with the C2000 team and the fix for CCS should be in CCS 10.0 and greater. The migration for C2000Ware to CCS 10.x is planned for 3Q this year.

    Thanks

    ki

  • Also, I did have a look at the other thread, but the suggested solution does not work for me.  Altering the values in the registers within our register strucs, while it shows the memory map prevented reading message, results in values that are being attempted to be written do not get reflected in the register view, so just using the register view isn't a solution in this case as far as I can see.

  • Did you try updating to CCS 10.0? The fix in CCS may be enough for the expressions view to access the memory correctly. 

  • Thanks. If this issue is not one that is likely to be resolved quickly, is there any suggestion for 9.3 on this problem?

  • The seg fault during the build was coming from the compiler that came with CCS 10. You can configure CCS 10 to use the compiler from CCS 9.3.0 to build. 

    See the below article on how to have CCS discover other compiler installations:

    https://software-dl.ti.com/ccs/esd/documents/ccs_compiler-installation-selection.html#compiler-discovery

    And how to select between different discovered versions:

    https://software-dl.ti.com/ccs/esd/documents/ccs_compiler-installation-selection.html#compiler-selection

    Thanks

    ki

  • Thanks, I'll attempt to rebuild with the 9.30 compiler within 10.0 and see if this issue resolves itself.

  • Sounds good. Keep us posted on your progress. 

    Thanks

    ki

  • I ran into some issues with getting the board to boot (getting stuck in itrap, but that is likely a separate issue).  

    To get more information on this issue, I tried to instance the registers directly with the following first

    #define testRegs
    #ifdef testRegs
    extern "C"
    {
    /*
    * ----------------------------------------------
    * Linked instance of SCI registers within memory
    * ----------------------------------------------
    */

    #pragma DATA_SECTION("CanaRegsFile")
    volatile struct f2837xd::can::impl::regs::CAN_REGS CanaRegs;

    #pragma DATA_SECTION("CanbRegsFile")
    volatile struct f2837xd::can::impl::regs::CAN_REGS CanbRegs;

    }
    #endif

    Then the main that instanced the register directly, and tried to change the values.    What I observe is that the TSEG1 and TSEG2 do not change from 0 to 2 as it is suppose to.  I tried with the CAN registers on page 3 (with both cmd and gel files set as such), and also attempted using page 1 on both, but in both cases, I get this same result.

  • Instanced the code up one more level, with a wrapper class that provides access API to the registers, and get the same results. In this case,  I made sure the initialize bits were set prior to the tseg1 and 2 to see if the registers responded appropriately.  Unfortunately as shown in this picture,  the register content are not getting tied to the register activity, and when I look into the register structs themselves, they also do not retain the values I specified.


  • John,

    Can you provide a small sample test case for me to try on my end? The simpler the better. I'm looking for full project and source files. I would just need any custom files as I have C2000Ware installed.

    Thanks

    ki

  • Here is a simplified project that uses the register class that we have, which had the same behavior that I was observing in the top level API classes we made as well (where the values written are not observed).   Hopefully the file shows up.  I cleaned the project so that it has the bare minimal and no references to other files in our designs.  The files should be almost all TI file derivatives I believe in this case.

    F28379D_Sandbox_simple.7z

  • Thanks John. I can reproduce the issue you describe. But it looks like the original memory map errors in the Expressions view have gone away in CCSv10 since it is correctly mapping to the Peripheral page.

    As for the current issue, I believe it is an issue with the the CAN registers not being properly initialized? This is a bit out of my expertise. I'll need to bring this to the attention of C2000 experts.

    Thanks

    ki

  • The original memory map error does seem to have been resolved, though that is likely due to moving to CCS 10.  On 9.3 we also had it set to page 3 without any luck.  However, now we are at the current issue.

  • I think I might have found the issue:   We need to set bits in the pClk register (3.15.11.14 in the Tech spec).    Going to try that and will report back.

  • This looks like it was the issue:  

    I added write APIs for the PclkCr10Reg for enableing CanA and CanB, and added that to my startup sequence.   Now the registers are responding as hoped.  Thanks for the help.

  • Glad to hear you resolved the issue. Thanks for sharing the solution!

    ki