Need help with Flashing MCU with OpenOCD

Go To Last Post
3 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I've managed to get really stuck with a project and I'm not sure how to fix it.

I have a small DIY development board with a Microchip SAMD10 MCU on it.

I have 2 laptops - an old Macbook Pro (~2010) with Ubuntu installed, and a newer Macbook Pro on which I've recently installed Mint 19.2.

On Ubuntu I was using OpenOCD to program my dev board with a cheap USB STLink v2 clone. I'd had to apply a patch to OpenOCD to make it work properly but it was working fine with Ubuntu.

I'm attempting to get things working now under Mint, but it's not working properly. I've followed the same steps I took to get it working with Ubuntu. When I try to upload the firmware, the function that I patched doesn't work properly and it fails.

But it doesn't fail every time. Sometimes it will flash the firmware successfully.

I added some debugging code to the function that is failing ( samd_issue_nvmctrl_command() ). When upload is successful, the function is called 10 times for the program I'm uploading. Sometimes it fails on the first call, sometimes the second etc etc.

I've tried quite a few things - including ensuring that both laptops were compiled from the same source version. I even copied the OpenOCD binary from the working laptop to the new one but this made no difference.

This leads me to suspect that the problem is actually with the OS somewhere interfering with the USB transfer.

I'm at a loss as to where I can look to try and diagnose the issue, so I was hoping someone might have some experience?

Thanks
-Mike

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Let’s start with the hardware. Can you post a picture of your diy board?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Let’s start with the hardware. Can you post a picture of your diy board?

 

Hi Kartman,

 

  I've been hacking at this on and off for most of the day and managed to get it working about half an hour ago! I have no idea **why** it now works, but it does.

 

Here's the board I made.

 

I was trying to work out exactly where OpenOCD was falling over, so I sprinkled a bunch of LOG_INFO(" *** Got Here ***") calls in the function I suspected as being the problem.

 

In trying to get more information on the state of the MCU, I added a call to target_read_u16() just after it writes the NVM command (OpenOCD actually calls the read function to get the return value for the NVM command function, but it does a few things before that, and I wanted to see what was going on between the write command and the subsequent read).

 

And as if by magic, the whole thing worked fine. I extracted all of the LOG_INFOS and left the pointless read and it still worked. I've called it a win, but I have absolutely no idea why it works.

 

here's the final code for the NVM command function:

//source file: src/flash/nor/at91samd.c

static int samd_issue_nvmctrl_command(struct target *target, uint16_t cmd)
{
    int res;

    if (target->state != TARGET_HALTED) {
        LOG_ERROR("Target not halted");
        return ERROR_TARGET_NOT_HALTED;
    }

    /* Issue the NVM command */
    /* STLink v2 doesn't like u16 writes here, but will work with u32 */
    res = target_write_u32(target,
            SAMD_NVMCTRL + SAMD_NVMCTRL_CTRLA, SAMD_NVM_CMD(cmd));

    /* Read target status
       This solves an issue with the STLink v2 programmer
    */
    uint16_t status;
    target_read_u16(target,
            SAMD_NVMCTRL + SAMD_NVMCTRL_STATUS, &status);

    if (res != ERROR_OK)
        return res;

    /* Check to see if the NVM command resulted in an error condition. */
    return samd_check_error(target);
}

I'd love to know what the actual problem was/is, but I don't think I'll find out! I'm nothing if not consistent in my ignorance.

 

-Mike

Last Edited: Wed. Nov 20, 2019 - 09:09 PM