PSoC™ Creator & Designer Forum Discussions

Hi all,
I've created memory section in linker script.

my_ram (rwx):ORIGIN = 0x08020000, LENGTH = 0x02000

    .mysection (NOLOAD):

    {

        KEEP(*(.mysection))

    } > my_ram

And allocated structure to it like this in "main_cm4.c"

volatile bmt_ble_buffer_t bmt_ble_buffer  CY_SECTION(".mysection")={.write_idx=0, .write_len=0, .ble_notify=0, .buffer[0][0]=0 };

I have issue - VectorDataPointer does not take correct address.
As you can see below, buffer address within structure is 0x0802009. This is as supposed to be and shows correct in Watch.

However, after running 1 more step in debug, VectorDataPointer gets random value - 0x09F9C229 - you can see it in Watch1 window below.
Why address cannot be assigned to pointer?
Pointer value is definitely wrong, because program get exception later when this pointer get used.

bmt_ble_buffer initialized fully prior getting this function.

What I'm doing wrong?

PS. If I change bmt_ble_buffer to static or remove memory allocation, then all fine,
but I cannot use it that way. I need this structure in other files and processes too.

Summary: Can we include the source code from cybootloaderutils in our (open source) utility for programming PSoC?

Hi, we are building an hardware platform based on PSoC. The cybootloaderutils source code only says

********************************************************************************

* Copyright 2008-2013, Cypress Semiconductor Corporation.  All rights reserved.

* You may use this file only in accordance with the license, terms, conditions,

* disclaimers, and limitations in the end user license agreement accompanying

* the software package with which this file was provided.

*******************************************************************************/

Can anyone point me to the license that this refers to?

I only can start the PSoC creator after start the PC (Windows 10 64bits and PSoC Creator 4.2). If I start any other program, when I try to start PSoC, it does nothing. The same things occurs if I try to open a new instance of PSoC or if I close it and I try to open again. If I close the PSoC by error, I need to restart the PC to open it again.

This week I was uninstalled the PSoC creator 4.2 and I was installed it again and the issues continues here.

Anyone had the same problem and know how fix it.

Thanks you.

Hi,

Using an ADC_DelSig with the CY8CKIT-059, I've noticed that in the ADC_DelSig there was an embedded Mux (that I could see in the main.c of PSoC Creator and on the datasheet of the ADC) But nowhere have I seen a way to use it. I know I can "just" use an AMux on the outside of the ADC, but my curiosity was peaked

If anyone can help me and knows how it works

Have a very nice day

A. Glibert

Recently I ran into an issue, where I passed a floating point variable over the stack to a function:

void WriteBuffer(sampleContext_t* pContext, float value);

The call was made in an ISR, and I was able to set a breakpoint on the function, which was hit.

void SAR_Interrupt(void)

{

     <code using several floating point variables>

     ...

     WriteBuffer(pContext, fVal);

}

The moment I tried to step into the function call, the debugger ended with:

~"/home/build/work/GCC-5-0-build/src/gdb/gdb/regcache.c:176: internal-error: register_size: Assertion `regnum >= 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_num_pseudo_regs (gdbarch))' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? "

~"/home/build/work/GCC-5-0-build/src/gdb/gdb/regcache.c:176: internal-error: register_size: Assertion `regnum >= 0 && regnum < (gdbarch_num_regs (gdbarch) + gdbarch_num_pseudo_regs (gdbarch))' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nCreate a core file of GDB? "

Error: dbg.M0015: Debugger exited unexpectedly during run.  Encountered error (GDB encountered an error and had to close.  See output window for more information. See output window for more information.)

CANCEL

I did found a couple of work-arounds:

1.  Eliminate (simplify) the <code using several floating point variables>

2.  Change void WriteBuffer(sampleContext_t* pContext, float value);

            into void WriteBuffer(sampleContext_t* pContext, float* value);

    which now passes a pointer to the value rather than the value it self over the stack.

But why did this debugger crash happen?

Interesting enough I discovered a thread regarding this similar error on a NXP forum (https://community.nxp.com/thread/389948​), which lead me to believe that this has to do with the floating point registers of the ARM cortex M4 processor, see https://www.sciencedirect.com/topics/computer-science/floating-point-register, Which states:

"S0 to S15 are caller saved registers. So if a function A calls a function B, function A must save the contents of these registers (e.g., on the stack) before calling function B because these registers can be changed by the function call (e.g., return result). S16 to S31 are callee saved registers. So if a function A calls a function B, and function B needs to use more than 16 registers for its calculations, it must save the contents of these registers (e.g., on the stack) first, and must restore these registers from the stack before returning to function A.The initial values of these registers are undefined."

My assumption is that the gdb in the PSoC Creator does not support S16..S31, and as soon a this condition occurs (which is only when debugging code that uses these registers) the debugger bows out ungracefully.... 

Now to the point: When debugging there is a register window (Toolbar => Debug => Windows => Registers) which only shows the "Regular" registers, but NOT the floating point (S1.. S31) registers...

How to view those floating point registers?

Hello.

I am trying to build a project using cypress project manager through CLI. The project is built successfully from the PSoC Creator, as well as using CLi via Powershell

./cyprjmgr.exe -w "C:\Users\ADMINRG\Desktop\BLEWORK\BLEWORKSPACE.cywrk" -rebuild -t "ARM GCC 5.4-2016-q2-update" (1)

However when I add pdlPath argument, it comes up with an error.

./cyprjmgr.exe -w "C:\Users\ADMINRG\Desktop\BLEWORK\BLEWORKSPACE.cywrk" -rebuild -t "ARM GCC 5.4-2016-q2-update" -pdlPath "I:\OtherPDLS\PDL\3.1.0" (2)

However it works if I tried this.

./cyprjmgr.exe -w "C:\Users\ADMINRG\Desktop\BLEWORK\BLEWORKSPACE.cywrk" -rebuild -t "ARM GCC 5.4-2016-q2-update" -pdlPath "C:\Program Files (x86)\Cypress\PDL\3.1.0" (3)

The otherPDLS Folder contains different PDL Versions. I copied them to another directory to save disk space on my C:/ Drive.

Inside PSoC Ceator, redirecting to the PDL folder "I:\OtherPDLS\PDL\3.1.0" and building does not cause any problems, but shows

Info: prj.M0282: A project is being renamed. Would you like to rename these related files as well?

YES

Analog Placement...

Analog Routing...

Analog Code Generation...

Digital Placement...

Digital Routing...

Bitstream Generation...

Bitstream Verification...

Static timing analysis...

API Generation...

Dependency Generation...

Cleanup...

Error: prj.M0007: The path or filename "${CyRoot}" is not supported: Filename must begin with letter, digit, or underscore ('_')..

ADD: prj.M0193: error: Failed while attempting to update project 'BLEWORK': Filename must begin with letter, digit, or underscore ('_')..

ERROR: Failed while attempting to update project 'BLEWORK': Filename must begin with letter, digit, or underscore ('_').

Thanks

I was wondering if it is normal that a Timer (UDB 24bit on the BUS_CLK) does not trigger the interrupt line on Capture even if the documentation indicate they are all ORed together (Yes I did select the On Capture interrupt option and yes I read the status register). The Capture_out does work. It has taken me 2 days to figure that out through many tests configuration. Is there something I should know? Is there some condition preventing this line to work as it should. I perform the test on a CY8CKIT-059 PSoC 5LP. I was working on a CY8CKIT-001 last year.

Thank you

Hi,

I flagged a bug back in 2016 for Creator 3.3 (Customization of keyboard shortcuts lost in PSoC Creator 3.3 SP2 ), then back in 2017 for Creator 4.1 (Losing keyboard shortcuts customization when debugging ). I was told that the bug would be resolved with Creator 4.2, but it's still there with Creator 4.3. This is really bothersome, as I need to always reenter my custom keyboard commands.

Has the bug just been ruled as not fixable?

Fred

I have a project using a PSoC5LP device compiled using PSoCCreater 4.2.

I am trying to use a fixed function Counter component as a watchdog timer. The counter generates an interrupt when the counter reaches its terminal count which generates a software reset.

I have named the counter 'Fido'. I call Fido_Start() at the start of my program, and periodically call Fido_WriteCounter(1200) to reset the counter to 1200 thus preventing it from reaching the terminal count and generating a reset unless the program crashes, in which case the counter will not be set to 1200, but will continue to count down to zero and generate an interrupt.

When I run the program, the first time Fido_WriteCounter(1200) is called, the program hangs.

Analysing the compiler-generated source file Fido.c

Fido_Start() calls Fido_Enable() which sets the enable flag by executing the statement

Fido_GLOBAL_ENABLE |= Fido_BLOCK_EN_MASK;

in Fido_WriteCounter(uint16 counter)         it executes the statement

CYASSERT (0u == (Fido_GLOBAL_ENABLE & Fido_BLOCK_EN_MASK));

As the enable flag in Fido_GLOBAL_ENABLE was set in Fido_Start() the if statement equates to zero, passing zero to  CYASSERT  which causes the cpu to be halted!

Should I disable the counter before calling Fido_WriteCounter() ?

The only high level API function which clears the enable bit in Fido_GLOBAL_ENABLE  is Fido_Stop()

Should I be calling Fido_Stop()?

Assuming the enable flag in Fido_GLOBAL_ENABLE  is clear when I called Fido_WriteCounter(),it would get past the statement

CYASSERT (0u == (Fido_GLOBAL_ENABLE & Fido_BLOCK_EN_MASK));

and immediately set the enable flag by executing  the statement

        Fido_GLOBAL_ENABLE |= Fido_BLOCK_EN_MASK;

Then writing data to the counter register before immediately clearing the enable flag by executing the statement

Fido_GLOBAL_ENABLE &= ((uint8)(~Fido_BLOCK_EN_MASK));

The counter would remain disabled until the next time I called Fido_WriteCounter();

This seems all wrong to me!

Am I misinterpreting the program?

Am I missing something?

or is there a bug in the compiler-generated Fido.c?

I have the following configuration settings in PSoC Creator

16bit Fixed Function

Period 1500

Run Mode: Continuous

Interrupt on TC

The version number for the Counter component is 3.0

The version number for PSoC Creator is 4.2

A copy of Fido.c is attached.

I originally tried using the built-in watchdog timer defined in CyLib.c

I started the Watchdog by calling

CyWdtStart(CYWDT_1024_TICKS  , CYWDT_LPMODE_NOCHANGE );

then periodically calling CyWdtClear();

When the program starts, I test the value of CyResetStatus, and if the CY_RESET_WD    bit is set, I take action to recover the error.

I modified my program so that it would deliberately get stuck in an infinite loop.

The Watchdog timer generated a reset 

but on testing the value returned by CyResetStatus,  the only bits that are set are

CY_RESET_SW                  and CY_RESET_GPIO1             

There is no sign of the supply voltage dipping during reset which could be interpreted as a normal power-on reset.