conflicting types for '_putchar'

RE: conflicting types for '_putchar'

madhu — Tue, 07 Aug 2018 17:47:39 GMT

Hi , I observed the same issue with 3.40 SES and SDK_15...
The above solution worked fine .

RE: conflicting types for '_putchar'

tesc — Fri, 22 Jun 2018 14:39:28 GMT

Hi,

Thanks for pointing that out.

At the time we did not have official SES support in the SDK, and so there was no release note recommendation available. Now that we do have official SES support the recommendation is to use the version for which the SDK release was tested and verified.

If there is no statement of supported version then using the latest version is usually the best bet, and if that does not work you may find a solution through DevZone.

Regards,
Terje

RE: conflicting types for '_putchar'

awneil — Fri, 22 Jun 2018 13:37:53 GMT

[quote userid="8164" url="~/f/nordic-q-a/34784/conflicting-types-for-_putchar/137159"]we always recommend the versions listed in the release notes for the particular version of the SDK[/quote]

Actually, you don't - see: https://devzone.nordicsemi.com/b/blog/posts/segger-embedded-studio-a-cross-platform-ide?CommentId=e94a1633-e277-45b1-93c1-abfaba042028

RE: conflicting types for '_putchar'

tesc — Thu, 21 Jun 2018 16:24:53 GMT

Hi,

I would not go as far as to say that Segger broke anything. SDK 15.0.0 was tested and verified using SES 3.34, and so that is the version supported. We do not (and for obvious reasons can not) guarantee forwards compatibility with development tools, and hence we always recommend the versions listed in the release notes for the particular version of the SDK.

However, things tend to work with other toolchain versions, and that is great! In the rare occasions when we get toolchain compatibility issues we do our best to provide a workaround, as was done by Martin Lesund in this thread. We do know that for some of you being able to run on a different version of the toolchain matters.

Regards,
Terje

RE: conflicting types for '_putchar'

awneil — Thu, 21 Jun 2018 14:00:06 GMT

I see.

So Segger broke it, then?

RE: conflicting types for '_putchar'

Martin Lesund — Thu, 21 Jun 2018 13:44:14 GMT

Hi Andrew,

You are correct.

Unfortunately, this change came with the new version of SES v3.40, and the SDKv15 was released before that update.

From the SDK v15 release notes:

The following toolchains/devices have been used for testing and
verification:
- SES: SES 3.34
[...]

You have two options:

Use the recommended version of SES v3.34.
Use the solution posted in this thread.

Best Regards,

Martin L.

RE: conflicting types for '_putchar'

awneil — Thu, 21 Jun 2018 13:04:50 GMT

[quote userid="66115" url="~/f/nordic-q-a/34784/conflicting-types-for-_putchar/133589"]I have confirmed that this issue is for SDK v14.2 with the new SES v3.40[/quote]

And it is still a problem with SDK v15.0.0 !

RE: conflicting types for '_putchar'

Martin Lesund — Tue, 29 May 2018 09:30:07 GMT

Hi Winston,

SEGGER has added the prototype for _putchar() in stdio.h, but the declaration of this prototype has a different type of variable.

See below:

stdio.h (line 773)

// Macro version of putchar.
#ifndef __PRINTF_TAG_PTR_DEFINED
#define __PRINTF_TAG_PTR_DEFINED
typedef struct __printf_tag *__printf_tag_ptr;
#endif
int __putchar(int, __printf_tag_ptr);
#define putchar(x) __putchar(x, 0)

Solution:

To solve this issue, we need to change the type of value in __putchar to __printf_tag_ptr instead of FILE *.

before: (retarget.c, line100)

int __putchar(int ch, FILE * p_file)
{
    UNUSED_PARAMETER(p_file);

    UNUSED_VARIABLE(app_uart_put((uint8_t)ch));
    return ch;
}

after:

int __putchar(int ch, __printf_tag_ptr p_file)
{
    UNUSED_PARAMETER(p_file);

    UNUSED_VARIABLE(app_uart_put((uint8_t)ch));
    return ch;
}

RE: conflicting types for '_putchar'

Martin Lesund — Mon, 28 May 2018 08:13:21 GMT

Hi Winston,

I have confirmed that this issue is for SDK v14.2 with the new SES v3.40. I do not know the reason for this as for now.

I would recommend you to downgrade SES to v3.34 or change to SDK v15 (where this issue does not appear).