Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NUCLEO_G031K8: Add new target #13006

Merged
merged 9 commits into from
Aug 26, 2020
Merged

Conversation

AGlass0fMilk
Copy link
Member

Summary of changes

Added support for NUCLEO_G031K8 target

Impact of changes

Migration actions required

Documentation


Pull request type

[X] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

Test results

[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[X] Tests / results supplied as part of this PR

GCC ARM Version Info:

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
Copyright (C) 2019 Free Software Foundation, Inc.

Testing results still pending... I have a NUCLEO_G031K8 board on the way...


Reviewers

@jeromecoutant
@ARMmbed/team-st-mcd


@AGlass0fMilk AGlass0fMilk changed the title NUCLEO_G031K8: Add new platform NUCLEO_G031K8: Add new target May 22, 2020
@AGlass0fMilk
Copy link
Member Author

I have blinky compiling. Still waiting on my NUCLEO_G031K8 board to arrive. I figured I would submit this PR for review anyway so I can get feedback from the ST team.

I will run mbed tests when my board comes in.

@ciarmcom ciarmcom requested review from jeromecoutant and a team May 22, 2020 05:00
@ciarmcom
Copy link
Member

@AGlass0fMilk, thank you for your changes.
@jeromecoutant @ARMmbed/mbed-os-maintainers please review.

Copy link
Collaborator

@jeromecoutant jeromecoutant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't test, but looks OK except minor updates
Thx!

Comment on lines 174 to 176
LED2 = PC_6,
LED3 = PC_6,
LED4 = PC_6,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove them



// This board does not have any buttons (aside from reset)
USER_BUTTON = PC_13,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is no button, we should not define it ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought this was a required PinName (like LED1) but I will look through mbed-os to see if there's any reference.

@@ -19,6 +19,11 @@

#define UART_NUM (5)

// Retarget this IRQn symbol for chips without USART3/4
#if defined(STM32G031xx)
#define USART3_4_LPUART1_IRQn LPUART1_IRQn
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK,
we should make this cleaner later

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'm open to suggestions. The family-level G0 implementations seem to be oriented towards only the G07x series. This was how I fixed it in the simplest way.

targets/targets.json Outdated Show resolved Hide resolved
targets/targets.json Outdated Show resolved Hide resolved
"extra_labels_add": [
"STM32G0",
"STM32G031xx",
"STM32G031K8"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To remove
TARGET_STM32G031K8 directory doesn't exist

targets/targets.json Outdated Show resolved Hide resolved
Comment on lines 2790 to 2791
"detect_code": [
"0221"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this "detect_code" are not used any more in mbed...
But correct code is "0852" for NUCLEO_G031K8

Maybe you have to push a PR in https://github.com/ARMmbed/mbed-os-tools ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where do you find the correct detect codes for each nucleo board?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be the 4 first digit of code Id of MBED.HTM file...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved with 47b42a6

Copy link
Contributor

@0xc0170 0xc0170 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jeromecoutant , I'll set this as changes needed

@adbridge adbridge added the release-type: patch Indentifies a PR as containing just a patch label Jun 11, 2020
@0xc0170
Copy link
Contributor

0xc0170 commented Jun 24, 2020

@AGlass0fMilk Any plans to update this PR?

@AGlass0fMilk
Copy link
Member Author

Yes I will work on this more in the next few days.

@pilotak
Copy link
Contributor

pilotak commented Jul 17, 2020

@AGlass0fMilk any update on this PR?

@mergify
Copy link

mergify bot commented Jul 17, 2020

This PR cannot be merged due to conflicts. Please rebase to resolve them.

targets/targets.json Outdated Show resolved Hide resolved
},
"device_has_add": [
"SERIAL_ASYNCH",
"MPU"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the "FLASH" component is missing here otherwise "FLASHIAP" would not work

targets/targets.json Outdated Show resolved Hide resolved
@pilotak
Copy link
Contributor

pilotak commented Jul 23, 2020

When trying to compile a simple program i'm getting an error

../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/bin/ld.exe:./BUILD/NUCLEO_G031K8/GCC_ARM/.link_script.ld:90 cannot move location counter backwards (from 20002170 to 20001c00)
collect2.exe: error: ld returned 1 exit status

@0xc0170 what if i submit a new PR because this one seems to dead or maybe @AGlass0fMilk can give me an access so i can do requested changes here

@0xc0170
Copy link
Contributor

0xc0170 commented Jul 31, 2020

@pilotak if you can, send a new PR (@AGlass0fMilk can fetch your remote, and send PR to your fork to help) ? I'll close this as it has been idle for some time, always can be reopened with an update.

@0xc0170 0xc0170 closed this Jul 31, 2020
@mergify mergify bot removed needs: work release-type: patch Indentifies a PR as containing just a patch scope: new-target labels Jul 31, 2020
@AGlass0fMilk
Copy link
Member Author

Sorry, this kind of fell to the bottom of my list... I will finish it sometime when it gets back to the top.

@mergify mergify bot dismissed 0xc0170’s stale review August 24, 2020 12:53

Pull request has been modified.

@AGlass0fMilk
Copy link
Member Author

@jeromecoutant @0xc0170 See updated target configuration with bare-metal profile as default.

This should hopefully fix the CI issues -- they look like they were caused by out-of-memory issues during linking.

@mbed-ci
Copy link

mbed-ci commented Aug 24, 2020

Jenkins CI Test : ✔️ SUCCESS

Build Number: 2 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_build-ARM ✔️
jenkins-ci/mbed-os-ci_build-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_dynamic-memory-usage ✔️
jenkins-ci/mbed-os-ci_greentea-test ✔️
jenkins-ci/mbed-os-ci_cloud-client-pytest ✔️

@jeromecoutant
Copy link
Collaborator

Jenkins CI Test : ✔️ SUCCESS

Build is now OK, but NUCLEO_G031K8 has been skipped :-)

@0xc0170
Copy link
Contributor

0xc0170 commented Aug 24, 2020

It should have been run. I've checked and it was not, the target should be available for building.

cc @ARMmbed/mbed-os-tools please review as well

Copy link
Contributor

@Patater Patater left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one json formatting nit. Otherwise looks alright from the tools point of view.

targets/targets.json Show resolved Hide resolved
@AGlass0fMilk
Copy link
Member Author

@Patater @0xc0170 @jeromecoutant Please review. What's the problem with CI?

@jeromecoutant
Copy link
Collaborator

What's the problem with CI?

CI status is green, but CI doesn't build baremetal only targets. :-)

@0xc0170 build has been verified manually, you can merge!

@0xc0170
Copy link
Contributor

0xc0170 commented Aug 25, 2020

Ci started, once all green will be merged

@mbed-ci
Copy link

mbed-ci commented Aug 25, 2020

Jenkins CI Test : ✔️ SUCCESS

Build Number: 3 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs Status
jenkins-ci/mbed-os-ci_unittests ✔️
jenkins-ci/mbed-os-ci_build-ARM ✔️
jenkins-ci/mbed-os-ci_build-GCC_ARM ✔️
jenkins-ci/mbed-os-ci_dynamic-memory-usage ✔️
jenkins-ci/mbed-os-ci_greentea-test ✔️
jenkins-ci/mbed-os-ci_cloud-client-pytest ✔️

@0xc0170 0xc0170 added the release-type: patch Indentifies a PR as containing just a patch label Aug 26, 2020
@0xc0170 0xc0170 merged commit afcf91f into ARMmbed:master Aug 26, 2020
@mergify mergify bot removed the ready for merge label Aug 26, 2020
@jamesbeyond
Copy link
Contributor

What's the problem with CI?

CI status is green, but CI doesn't build baremetal only targets. :-)

@0xc0170 build has been verified manually, you can merge!

the baremetal list is manually maintained in CI, we can manually add it once this merged

@jeromecoutant
Copy link
Collaborator

Quick update on webpage: https://os.mbed.com/platforms/ST-Nucleo-G031K8/

@AGlass0fMilk
Copy link
Member Author

Quick update on webpage: https://os.mbed.com/platforms/ST-Nucleo-G031K8/

Typo in URL on that page:

But since mbed-os-6.2.2, it is available on github repo: https://github.com/ARMmbed/mbed-os/tree/master/targets/TARGET_STM/TARGET_STM32G0/TARGET_STM32G031xx/TARGET_NUCLEO_AG031K8

TARGET_NUCLEO_AG031K8 should be TARGET_NUCLEO_G031K8

@jeromecoutant
Copy link
Collaborator

Thx
I also added the production issue and the workaround to do in order to enable correct binary drag and drop feature.

@mbedmain mbedmain added release-version: 6.3.0 Release-pending and removed release-type: patch Indentifies a PR as containing just a patch Release-pending labels Sep 14, 2020
@ObeidHaidar
Copy link

I keep getting the following error when trying to use I2C2 pins A4(PA_12) and A5(PA_11)

++ MbedOS Error Info ++
Error Status: 0x80FF0100 Code: 256 Module: 255
Error Message: Fatal Run-time error
Location: 0x80038F3
Error Value: 0x0
For more info, visit: https://mbed.com/s/error?error=0x80FF0100&tgt=NUCLEO_G031K8
-- MbedOS Error Info --
I2C: unknown instance

Code works fine when I use any of the other SPI1 pins.

Checked the PeripheralPins.c file for the board and it seems fine.

example of code that would fail:

#include "I2CSlave.h"
#include "I2C.h"
#include <cstdio>
#include <string.h>
#define SLAVE_ADDR 0xA0
#define BUFFER_SIZE 6

I2C master(A4,A5);

static const char* to_send[] = { "abcde", "12345", "EFGHI" };

int main() {
    char buf[BUFFER_SIZE];
    int send_index = 0;
    while (1) {
        strcpy(buf, to_send[send_index]);
        // Write the new message to the slave
        if (master.write(SLAVE_ADDR, buf, BUFFER_SIZE)) {
            printf("Failed to write to slave!\n");
        } else {
            printf("Written to slave: %s\n", buf);
        }
        // Read what the slave has (should be identical)
        if (master.read(SLAVE_ADDR, buf, BUFFER_SIZE)) {
            printf("Failed to read from slave!\n");
        } else {
            printf("Read from slave: %s\n", buf);
        }
        // Change the message we're writing to the slave
        send_index++;
        if (send_index > 2) {
            send_index = 0;
        }
        wait_us(500000); // Wait 0.5s
    }
}

Can anyone try this and see if they get the same result?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.