• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 31 subscribers
  • Views 4331 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TM4C123GH6PM: No CANbus communication with Tivaware Bootloader with just the bootloader installed.

L Eberhard
Prodigy 70 points
Part Number: TM4C123GH6PM

Enabled CAN communication for the Tivaware flash based Bootloader. Successful CAN communication with the bootloader when it is called by the running application, but there is no response when the bootloader is powered on or reset without the application installed.

If an application is installed with the bootloader, a correct CRC will result in the application being loaded. Verified the flash bootloader is being called after installing an application with an incorrect CRC and the application did not run. The bootloader is also installed in the default address location.

Altered bl_can.c to support 11bit messages instead of 29bits, but this is used in the working call to the bootloader in addition to the lone bootloader start.

Bl_config.h has been altered to match the CAN and system control clock configurations in the calling application and found this thread to verify the pin configurations. https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/p/535111/2171193

Uncertain what additional setup step is missing when initializing the CAN connection through bl_can.c

Also uncertain how to verify the bootloader is executing all of the steps in the ResetISR of bl_startup_ccs.s

Thanks,

Eberhard

  • 0
    Guru 117855 points

    My friend - so many here "suffer" when attempting (for always unexplained reasons) to employ the bootloader.

    L Eberhard said:
    Altered bl_can.c to support 11bit messages instead of 29bits

    and

    L Eberhard said:
    Bl_config.h has been altered to match the CAN and system control clock configurations in the calling application

    To your issue - as I past worked in a similar semi "giant" - I know that staff here prefer your "sticking to the original set-up/config" as much as possible - which enables their most efficient assistance.     Yet - at minimum - you've created two "deviations" - which may confound vendor attempts to replicate your findings.

    Might it prove useful for you to "Remove each of those "alterations" - and run the code (and test) w/the "closest match to vendor code, possible?"  Should your "issues" persist - vendor then has a clear path to confirmation - and your "support" can only be increased...

    All here must "feel for" and be "sensitive to" the needs of the "limited vendor staff" - tasked to resolve so many issues - from so many.        Your "easing their job" by "removing alterations" seems a superior means to gain their attention & further support...      (I concede that your "CAN & system control clock configs" (appear) minor - but they're "unshown" - thus subject to error/misunderstanding.)

  • 0 in reply to cb1_mobile
    Prodigy 70 points
    Hi cb1_mobile,

    Thank you for your response and clarifications. I'm sorry for the errors of my original post and I hope this information is more useful.

    I switched to the 123g boot_serial demo point instead of the 129 example I had started with. The uart defines were commented out and these were the config modifications: (CAN0_Rx is connected to PB4 and CAN0_Tx is connected to PB5) The link I had added earlier is what I used to figure out what to set the PCTL defines. It seemed that post had also verified these ports work with the CAN bootloader.

    #define CAN_ENABLE_UPDATE

    #define CAN_RX_PERIPH SYSCTL_RCGC2_GPIOB
    #define CAN_RX_PORT GPIO_PORTB_BASE
    #define CAN_RX_PIN 4
    #define CAN_RX_PIN_PCTL 8

    #define CAN_TX_PERIPH SYSCTL_RCGC2_GPIOB
    #define CAN_TX_PORT GPIO_PORTB_BASE
    #define CAN_TX_PIN 5
    #define CAN_TX_PIN_PCTL 8

    the CAN_BIT_RATE was uncommented and the default 1000000 was kept.

    Following your suggestion, I kept the default bl_can files that were provided by TI to use the 29 bit message. I also only installed the bootloader onto the Tiva and restared the board. If I understand the startup script correctly, it should be in the bl_can.c while loop of UpdaterCAN waiting for a message.

    After sending the ping command, nothing is being sent back. If I step through with the debugger it jumps instead of stepping through the disassembly and outside of the program.

    Some searching in the forums mentioned that the debugger cannot step through code in SRAM without editing GEL files. I have no experience with this. Where would be the best place to find examples to accomplish this?

    Thank you for your time!
  • 0 in reply to L Eberhard
    Guru 117855 points

    My friend - no one seeks your sorrow - instead we wish to, "Speed, Ease, Enhance" the efforts of vendor's staff and/or (we outsiders) - who try to "pitch in" and offer assistance when & if able.

    I suspect that use of the CAN bootloader is the most little used - thus your accommodating the request for "better matching" vendor examples - is likely to raise vendor interest.      Some further specifics should assist vendor agents - or other 129 users - (firm/I do not use the 129) in assisting.

    Might you note the following (again, my hope is this proves helpful to vendor agents or those w/CAN expertise)"

    • have you a "real" CAN transceiver which feeds your MCU's CAN pins?
    • if so - does that transceiver specify operation at your 1M, CAN bit rate?     (Firm/I always find it preferable to "start" at lower speeds as these prove easier to "make work" - at least initially.
    • the 123 example code includes, "Simple RX/TX CAN" - and we've found that to be a great aid in bringing up the CAN bus.    Perhaps your 129 example presents a similar (simple) sample CAN program?
    • Never having used a CAN bootloader - I'm unsure if the Port you've chosen "overlaps" the one intended for bootloading.     If not you may have to change CAN ports and/or configure those MCU pins for CAN operation.     (that technique is well covered w/in the 123's "Simple CAN RX/TX code example.")
    • There is a special App Note which focuses upon the MCU's bootloader.      Have you found - and deeply reviewed - then well complied - with its guidance & instruction?
    • Perhaps "overkill" yet your (temporary) move "away" from the bootloader - instead to use of "Simple CAN RX/TX" in the attempt to establish (some) "far more basic" CAN communication with your "remote" CAN board.     (this being the board which will (later, hopefully) exercise the CAN bootloader )     My intent is to "positively establish" that your CAN configuration/attachment is "solid" - and that if there IS an issue - that it resides (solely) w/in the CAN bootloader.

    Many individual pieces form a "chain" - which stands between you (now) and your CAN Bootloader success.         My intent is to systematically determine, "What really works" - so that your odds of success significantly increase...     Good luck...

  • 0 in reply to cb1_mobile
    Prodigy 70 points
    Hi cb1_mobile,

    I have verified the CAN hardware. There is a sample program that will communicate over CAN with no issues and as long as the bootloader is activated by that sample program, I can reprogram the device through the CAN bus. It won't communicate only when that program is not loaded and the bootloader configures the IO. Remote programming also worked with the 11bit message changes that had been made. That code was common to both when the bootloader is called by the sample program and when the bootloader initializes.

    The 1M was an attempt to remove deviations. The sample code has had success at 500kb, but if I change the config file there is still no communication if the bootloader configures the IO.

    I've been reading both the Tiva TM4C123GH6PM Microcontroller datasheet and TivaWare Boot Loader user's guide to make the initial deviations and for debugging. I was able to add in code that will turn on LEDs to confirm the bootloader is reaching the while loop that waits for programming messages.

    I've been comparing differences between the standard Tivaware libraries and the bootloader source code. I'm hoping I might find something that may tell me if a configuration I set is wrong.

    Thanks again for your help.
  • 0 in reply to L Eberhard
    Guru 117855 points
    May I applaud the detail and systematic nature of your approach? Excellent.

    I noted the return of a vendor agent - seems best that I "make way" now for those who, "May have direct experience w/the CAN bootloader - and/or "insider detail" which is often (only) available to "insiders."

    At the minimum - there exists now a clear/clean "recital" of your issue - along with the key probings you've made in your strong attempt to achieve its resolution... Bon chance, mon ami...
  • 0
    Prodigy 70 points

    CAN Bootloader working:
    Attempted again to use the default serial_demo along with an oscilloscope to monitor the CAN communication instead of an application on the computer. Made the previous bl_config.h changes :
    #define CAN_ENABLE_UPDATE

    #define CAN_RX_PERIPH SYSCTL_RCGC2_GPIOB
    #define CAN_RX_PORT GPIO_PORTB_BASE
    #define CAN_RX_PIN 4
    #define CAN_RX_PIN_PCTL 8 //Pin's alternate function to be used

    #define CAN_TX_PERIPH SYSCTL_RCGC2_GPIOB
    #define CAN_TX_PORT GPIO_PORTB_BASE
    #define CAN_TX_PIN 5
    #define CAN_TX_PIN_PCTL 8 //Pin's alternate function to be used
    #define CAN_BIT_RATE 500000

    An additional change was made to bl_can.c in the while loop of void UpdaterCAN():
    //ui32Cmd = PacketRead(g_pui8CommandBuffer, &ui32Bytes);
    ui32Cmd = 0;

    This spammed an ACK that could be observed on the oscilloscope. Once that was confirmed, the remaining deviations were added back in and the bootloader can reprogram with and without a calling application. To assist others with debugging the bootloader, here are the register edits I made to the GPIOs for one of the diagnostic LEDs (It has not been pared down to the minimum needed registers):

    extern void Delay(uint32_t ui32Count);

    void InitLEDs(void)
    {
    //Enable Clock
    HWREG(SYSCTL_RCC) &= ~(SYSCTL_RCC_MOSCDIS);
    Delay(524288);
    HWREG(SYSCTL_RCC) = ((HWREG(SYSCTL_RCC) & ~(SYSCTL_RCC_OSCSRC_M)) |
    SYSCTL_RCC_OSCSRC_MAIN);

    //Enable the system control for the GPIO base. (Replace GPIOF with your LED base)
    HWREG(SYSCTL_RCGCGPIO) |= SYSCTL_RCGC2_GPIOF;
    Delay(3);
    }

    void SetLED0(void)
    {
    //0x04 is the bit for pin PF2 according to the datasheet. (Replace PORTF with your LED base and replace 0x04 with your pin value found in GPIO.h of the tivaware library)

    //Set drive strength to 2mA
    HWREG(GPIO_PORTF_BASE + GPIO_O_DR2R) = (HWREG(GPIO_PORTF_BASE + GPIO_O_DR2R)| 0x04);
    HWREG(GPIO_PORTF_BASE + GPIO_O_DR4R) = (HWREG(GPIO_PORTF_BASE + GPIO_O_DR4R)& ~(0x04));
    HWREG(GPIO_PORTF_BASE + GPIO_O_DR8R) = (HWREG(GPIO_PORTF_BASE + GPIO_O_DR8R)& ~(0x04));
    HWREG(GPIO_PORTF_BASE + GPIO_O_SLR) = (HWREG(GPIO_PORTF_BASE + GPIO_O_SLR)& ~(0x04));

    //Set the pin type to digital enable (standard)
    HWREG(GPIO_PORTF_BASE + GPIO_O_ODR) = (HWREG(GPIO_PORTF_BASE + GPIO_O_ODR)& ~(0x04));
    HWREG(GPIO_PORTF_BASE + GPIO_O_PUR) = (HWREG(GPIO_PORTF_BASE + GPIO_O_PUR)& ~(0x04));
    HWREG(GPIO_PORTF_BASE + GPIO_O_PDR) = (HWREG(GPIO_PORTF_BASE + GPIO_O_PDR)& ~(0x04));
    HWREG(GPIO_PORTF_BASE + GPIO_O_DEN) = (HWREG(GPIO_PORTF_BASE + GPIO_O_DEN)| 0x04);

    //Disable the analog function
    HWREG(GPIO_PORTF_BASE + GPIO_O_AMSEL) = (HWREG(GPIO_PORTF_BASE + GPIO_O_AMSEL)& ~(0x04));

    //Set the direction
    HWREG(GPIO_PORTF_BASE + GPIO_O_DIR) = (HWREG(GPIO_PORTF_BASE + GPIO_O_DIR)| 0x04); //Configure debug LED as output

    //set the mode
    HWREG(GPIO_PORTF_BASE + GPIO_O_AFSEL) = (HWREG(GPIO_PORTF_BASE + GPIO_O_PDR)& ~(0x04));

    //Set output high
    HWREG(GPIO_PORTF_BASE + (GPIO_O_DATA + (0x04 << 2))) = 0xFF;
    }

    Update (7/12/2017):

    After confirming that the CAN settings and the bootloader were correct, the modification in bl_can.c in the while loop of void UpdaterCAN() was removed and restored to;


     ui32Cmd = PacketRead(g_pui8CommandBuffer, &ui32Bytes);

  • 0 in reply to L Eberhard
    Guru 117855 points

    Glad to have noted your systematic approach - and "drive toward success."

    Sad to have noted the (pardon) unnecessary & overly complex "DRM protocol" - rather than vendor's API.

    Users here - attempting (any) change to, "Init or Set" Led (both coded exclusively in DRM) - are destined for a "rocky" shoreline...     And - as those code blocks have NO rapid execution - nor code space requirements - the choice of DRM (which adds great time/effort/complexity) appears to offer little merit...

  • 0 in reply to cb1_mobile
    Prodigy 70 points
    Hi cb1_modile,

    I agree that the method is overly complex. I wasn't sure if my diagnostic code should call the API since the rest of the bootloader did custom register edits. Is it okay to call the Tivaware library from the bootloader?

    Normally I do stick to the vendor API instead of direct register edits.

    Thanks!
  • 0 in reply to L Eberhard
    Guru 117855 points

    L Eberhard said:
    Is it okay to call the Tivaware library from the bootloader?

    It is "hoped" that such is ok!      (firm/I have no direct experience w/this vendor's bootloader - having migrated to Cortex M7 & Cortex R-52 (that for Autonomous designs.))

    I did not wish to "pile on" (further) yet I have concern re: your "spamming the ACK."      While inventive on your part - does that not signal (some) inconsistency or weakness w/in (either) your application code or hardware?     ((firm/I have never had to "spam" such signal - and (most) serious investors (and/or VCs) would, "Run for the exit" when such practice is admitted...    (w/cb1 "on their heels")

  • 0 in reply to cb1_mobile
    Prodigy 70 points

    Oh, that was only for debugging purposes. I restored the original command/response once it was confirmed that the settings were correct. The spamming test was to remove the possibility that the incoming commands were filtered out.

  • 0 in reply to L Eberhard
    Prodigy 70 points
    I just updated my answer to clarify I removed the spam edit for a working Bootloader. Thank you cb1_mobile for the reminder to add that in.
  • 0 in reply to L Eberhard
    Guru 27665 points

    L Eberhard said:
    Is it okay to call the Tivaware library from the bootloader?

    The API just manipulates the registers (it's easy enough to check). While it's possible some calls may be restricted, I'd be surprised if the vast majority didn't work fine.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points
    Agreed - it should be noted that "no" API (not even one from this hallowed vendor) offers a "complete set" of function calls. (thus to satisfy (some) requirements - DRM may be necessary)