expected fucntion body after function declaration

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi,

   

I am modifying someone else's code.   This is for a ham radio project.   At some point in time, with some previous version of Creator the attached code worked.  I have no idea what that version was.   The issue that I am experiencing is the when viewing the main.c source of the bootloader project is reporting: "expected function body after function declaration" at the line:

   

   

CY_ISR(morse_interrupt).  

   

 

   

 

   

   

Also, there many errors reported when viewing the morse_isr.c file. I'm sure it is something simple that I am over looking but I can't seem to clear the message(s) and I have a feeling this is causing the project not to function correctly. However, the code does compile without errors or warnings.  I'm confused

   

Background info:  The bootloader senses a "boot" pin and if active, initiates an interrupt routine to blink a led with a message, "BOOT" in this case and calls bootloader_start(). This is so Creator 3 bootloader host may upload new firmware.  (Note: the led_test is a bootloadble project for testing to determine if the bootloader project is functioning correctly)

   

 

   

If the pin is not active, it passes through this and starts the main program. 

If the new firmware is uploaded to the device with the miniprog3,  the device simply does nothing.  The USB interface is not activated and the LED does not blink.

   

I hope this makes sense.  Sorry for the multiple fonts.  IE does not play well with this web site. Thanks, Ron

0 Likes
21 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

There are some issues with PSoC3 and the on-line code checker which flags statements as errorneous that aren't bad. Trust in the compilation which will reflect the reality and -as I tried- there seem to be no compiler errors or warnings with your code.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hello Bob,

   

Thanks for coming back to me.  Bummer,  I was hoping the issue with the bootloader was something as simple as a missing definition (or along that line).  This means the cause of the issue of the bootloader not functioning is more deeply buried.  As I mentioned,  this code worked at one time.  As far as I know,  the source code is identical to the source that was compiled sometime about a year ago.

   

Thanks,

   

Ron 

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

The unconnected pin "BOOT" is driven high which will start the bootloader in code. Is that the polarity you wanted? Then, as I understand, the bootloader waits for 25 seconds for a command. That's what you want?

   

Why do you use a StatusRegister component and do not read the pin directly?

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

"The unconnected pin "BOOT" is driven high which will start the bootloader in code. Is that the polarity you wanted? Then, as I understand, the bootloader waits for 25 seconds for a command. That's what you want?

   

Why do you use a StatusRegister component and do not read the pin directly?"

   

All very good points.  I will check on the initial state of the pin.  I do know that the pin is taken to ground via a jumper when the user wants to upload new firmware.  After looking a the PCB schematic, the configuration of the pin and the code, something is not lining up (so to speak).  As for the 25 seconds on the bootloader that is a mistake on my part.  I was experimenting in an attempt to getting things to work.  The original set up has the bootloader set to an infinite wait.     Good point on the status of the pin.  As I have mentioned this was some else's code.  I will look into simply sensing the pin directly. 

   

 

   

Thanks so much for the help.

   

Ron

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

If you read a pin directly I suggest you bounce it in and out then execute

   

the boot. You might be able to get away w/o doing this. Possibly 

   

the length of time in boot update will allow this. If you debouce plan on

   

some crappy switches exceeding 100's of mS bouncing.

   

 

   

Regards, Dana.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Since you plan to jumper the BOOT-pin there will be no need for de-bouncing, instead it will be alright to read the pin after power-up and branch to the update-part of the bootloader when the pin reads zero.

   

 

   

Bob

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hello All,

   

Yes, the sequence of events are:1) Power down the device, 2) Move jumper to boot position, 3) power up,4) upload new firmware via bootloader host, 5) power down,, 6) move jumper to run position, 7) power up.  Obviously this is not intended to be used very often.  It is just not convenient.  Most users (operators) of this device will only be updating firmware on a very occasional basis (may be once every two years).  Updating is more frequent at the moment since I am modifying the firmware to add new functionality.

   

OK,  I have modified the project based on previous recommendations.  Please note I am updating the firmware via the miniprog3.  The miniprog3 is also used for debugging the code (forgive me if I am stating the obvious, but details are important when trouble shooting issues such as this). 

   

The firmware now works to a certain extent.  If the boot jumper is placed in the boot position the bootloader takes over and the LED is blinked with the morse code message, "LOAD" in this case.  Please note:  bootloader is configured to wait forever. 

   

However, if the jumper is not in the boot position (run) the device just sits there and does nothing (no message, no anything ).  So the question is how do I get the bootloader project to "jump" to the "led_test" program if the boot jumper is not in the boot position?  Please examine the main.c source in the bootloader project. 

   

As I have mentioned this has worked in the past.   The original author of this code supplies an original hex and elf file.  If I set the bootloadable component in the "led_test" project to point to these files,  everything works.  I just can't get the source he supplies to work after being recompiled with PSoC Creator 3 SP1.  

   

Thanks for your attention and patience.  Sometimes I can be "thick as a brick"

   

Ron

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

Good point about the hard wired jumper.

   

 

   

But then these days why do you have a customer opening up a box to

   

move a jumper ? Hopefully an exposed slide switch or a buttonat minimum.

   

But then amatuer radio operators drink a lot of fluids of various kinds, so fluid

   

proof the box would be well received. Hence tactile overlay button.

   

 

   

Just a thought.

   

 

   

Regards, Dana.

   

KB1RHB

0 Likes
Anonymous
Not applicable

Ah, a fellow ham.   This is the Peaberry V2 SDR radio.  It comes as a kit so there are already little hammy  fingers in it .  It really is good little rig.  It is a clone of the very popular Softrock Ensemble RTXT but the Peaberry uses the PSoC 3 to control all the functioning of the rig.   I am modifying the firmware to support internally generated CW / Iambic code.   As background, the rub with the softrock clones has been the CW paddles port has never functioned very well due to high latency issues.  But since the Peaberry has the PSoC3 and is almost totally firmware driven, it has been fairly straight forward to modify the original firmware to support real CW / Iambic operations (just like the big rigs do ).   The new firmware actually does work very well (it is in BETA and I'm waiting for feedback).  I just can't get the bootloader to work. 

   

Ron / W4MMP

   

P.S.  Some hams don't even have the Peaberry in a box.  It is simply laying naked on their table

   

http://ae9rb.com/index.php?main_page=product_info&cPath=1&products_id=8&zenid=592eb1b4c9ffed78b51ca4...

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Afaiutd (as far as I understand the datasheet) you have to call BootLoader_Start() in any case. To make that work for you, you should remove the infinite wait. Depending on your design (make connection to USB host first, set jumper, then power-up) you even may wait for just half a second or less. When the Bootloader is not star4ted there are only some dirty hacks to start the bootloadable.

   

 

   

Bob

   

 

   

Q: Why do java programmers always wear glasses?

   

A: The can't C#

0 Likes
Anonymous
Not applicable

Hi Bob,

   

OK, thanks very much.   I will give your recommendations much consideration.  But I have to asks.  What are the hacks?

   

 

   

Regards,

   

Ron

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

There is a variable telling the bootloader whether it was a software reset and now the bootloadable should run or if the bootloader must take over control. I never used that, but when yoou inspect the bootloader.h file you might find something.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

Along the line of being "thick as brick" it took a while to figure what is wrong   I located an old original source.  When the boot pin is not active this function call is made:  Bootloader_LaunchApplication .    Apparently PSoC Creator 3 SP1 no longer externalizes this call.  I found the call in the generated source file,  bootloader.c.  What do I set in my source so that I may call this function call?  This will solve the issue if I can call it directly from my application.  I put this in my source:

   

extern void Bootloader_LaunchApplication(void) CYSMALL;   but it didn't help.  Compiler still errors off with: Build error: L127: UNRESOLVED EXTERNAL SYMBOL SYMBOL: Bootloader_LaunchApplication .  Is there something I need to set up in the lnker?

   

Thanks,

   

Ron

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Here is the fricken hack:

   

Bootloader_SET_RUN_TYPE(Bootloader_START_APP);

   

CySoftwareReset();

   

use that in main()  to switch to Bootloadable.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

 Thank you, thank you, thank you!!!  That did the trick!.

   

I hope I have not annoyed with all of this and my questions.

   

Thanks again !

   

Ron

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Not annoyed at all, Ron. You are always welcome! You may go to lunch right now...

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

Just one last note .  I have submitted a case with Cypress regarding this issue.  Not sure how far it will go.   One thing I have noticed since with working with this technology,  while the chips themselves are very good and a great concept,  Cypress's regression testing for backwards compatibility leaves something to be desired.  I am a 25 year veteran of the CS and IT industries.  I guess I have been lucky,  the two major companies I have worked for during that period of time, had an absolute commitment to backwards compatibility.  This not the first instance while working with this ham radio application where PSoC Creator 3 SP 1 is not compatible with the previous releases.  The other issue was resolved fairly easily.  This one was a bit sticky.    (Off soap box).

   

 

   

Thanks again,

   

Ron 

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

I think that keeping backwards compatibility can spoil the progress, can hinder to invent new technics, new chips. After some time the burden to support older designs or components can be a pain in the ass.

   

In the case of the BootLoader I agree with you that the function to start the bootloadable should not have been hidden but put into the .h-file to make it accessable from BootLoader.

   

 

   

Bob

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

But Creator comes with the older versions of all components. That should include the bootloader as well. You need to enable the display of hidden component (I think its somewhere in the preferences).

   

If you still have the original version of the project, you can also try to use it again, but this time without updating the bootloader.

0 Likes
Anonymous
Not applicable

From Cypress:

   
Hello Ronald,  Apologies for the inconvenience caused. Yes you are right. You will face issues with Bootloader_LaunchApplication().  This issue is due to the updates done to Bootloader component in version 1.20.  These issues are fixed in the upcoming version of bootloader component 1.30.  One workaround to avoid this issue is to use bootloader component 1.10 in your project.  You can do this by clicking on,  Project -> Update Components -> Bootloader select version 1.10 instead of 1.20. Now Click on next and update the component. After configuring Bootloader component to 1.10  you will not face issues with Bootloader_LaunchApplication() function.   Please let us know if this solves your issue. We are sorry for the inconvenience caused  due to this issue. This issue will be fixed in the latest creator version PSoC Creator 3.1. Please let us know if you have any further questions.  Thanks, Hima
0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Oh, I did not think of using the upgrade dialog to downgrade a component 🙂 But its easier I guess than replacing it (since it should retain the configuration, if any).

0 Likes