In my project NvM_Multi block and Config_block both are return the valus for NvRamErrorStatus_u8 as NVM_REQ_NOT_OK. While flashing the software there were no issues and the config block and multi block values are NVM_REQ_OK after few days of running the return value of the blocks are becomes NVM_REQ_NOT_OK. I have read AUTOSAR spec and understood config block value write as part of the write all before entering sleep and it will be stored, then the next wakeup cylce the config block shall return the value as NVM_REQ_OK. Here this is not happeneing and I presume block has been corrupted and is there any way to fix this issue. Luckily we found this issue during the long run test, if this issue is happening in field how this can be fixed? Could you guys please help.
NvM is BSW component that depends on lower layer components, i.e. Fee.
You should check with a debugger if the error comes from NvM or from the SW component below it.
Config block is a system specific block and you must not modify it. You should create a new user block and provide a lower layer block for it, i.e. create also a new Fee block.
Related
I am connected to our target over ethernet using the Linux TCF agent to debug an application.
I've used a lot of debuggers over my 25 year career, but this is my first time using Eclipse/Linux/Xilinx environment. I can set break points. I can single step through the code. I can view variables. I can view memory. I can type a new value in the memory location, but the variable value doesn't change. I tried to click or double click the value in the Variables pane. I tried right clicking to see if it would give me an option to modify the value.
I'm not sure what good a debugging tool is if I can't change a variable value to alter the execution path of my software...
In addition to the hacky solution we came up in the comments, which is to get the address of a variable and then modify them through the mr command from the xsct console, the same console provide commands to properly get/set a local variable.
The syntax is the following:
locals [options] [variable-name [variable-value]]
And an example:
locals my_int_var 10
locals my_float_var 1.4
i follow the instruction(below link) to set trigger to the current date time in Configuration Block
but the trigger={date}{time}; does not work, it return error
" the configuration block was not well-formed."
who know the right expression for the current date? thanks a lot
https://support.tibco.com/s/article/How-to-append-rows-and-update-data-table-on-a-frequent-basis
this looks like either a typo on the article, or a bug in the Automation Services Job Builder. you can get around this message by surrounding the values with quotes, so
trigger="{date}{time}";
while the quotes are not required (according to Configuration Block documentation), I would argue that it's a best practice because you never know if the value you're passing is going to jank up the configuration block parser.
also a tip: you can and probably should test any configuration blocks in the Web Player before deploying a job in Automation Services. when doing this, don't forget to URLEncode, like, everything. here's an example from the documentation I linked above:
http://spotfire.cloud.tibco.com/spotfire/wp/OpenAnalysis?file=/Gallery/Introduction%20to%20Spotfire&configurationBlock=SetFilter(
tableName=%22World%20Bank%20Data%22,columnName=%22Region%22,values=%7B%22North%20America%22,%22Europe%20%26%20Central%20Asia%22%7D);
and a link of that example in action.
This is a great package for Bayesian optimization of hyperparameters (especially mixed integer/continuous/categorical...and has shown to be better than Spearmint in benchmarks). However, clearly it is meant for Linux. What do I do...?
First you need to download swig.exe (the whole package) and unzip it. Then drop it somewhere and add the folder to path so that the installer for SMAC3 can call swig.exe.
Next, the Resource module is going to cause issues because that is only meant for Linux. That is specifically used by Pynisher. You'll need to comment out import pynisher in the execute_func.py module. Then, set use_pynisher:bool=False in the def __init__(self...) in the same module. The default is true.
Then, go down to the middle of the module where an if self.use_pynisher....else statement exists. Obviously our code now enters the else part, but it is not setup correctly. Change result = self.ta(config, **obj_kwargs) to result = self.ta(list(config.get_dictionary().values())). This part may need to be adjusted yet depending on what kind of inputs your function handles, but essentially you can see that this will enable the basic example shown in the included branin_fmin.py module. If doing the random forest example, don't change at all...etc.
I am facing an issue that I could not understand how to resolve.
I created a test plan that need to connect DB and count the results.
The problem is that Jmeter not perform any validation afterwards, I created a JSSR223 in the JDBC request and just want to print the results and Jmeter not print.
I created another sampler to print the DB results and still Jmeter not printing.
Jmeter just passes this steps,
In the results tree I saw that it connects to DB and failed in the assertion, but why it passes the other steps? and just moving to debug sampler?
I can not print the results, I can not perform any debug since it is just black box.
can someone please advise?
you can see in yellow all the steps that Jmeter not performed and just not exists in the results tree.
enter image description here
Get used to check jmeter.log file, it normally contains information regarding what went wrong, you should be able to figure out the root cause by looking into the log file. If you are not - update your question with jmeter.log file contents (at least essential parts)
My expectation is that your ${Conv_sense} variable is not defined (or cannot be cast to Integer). Double check whether it is defined or not using Debug Sampler and View Results Tree listener combination.
Also don't refer JMeter Variables like ${Conv_sense} in Groovy scripts body, use vars.get('Conv_sense}') instead, otherwise it might conflict with Groovy GStringTemplate resulting in undefined behavior.
disclaimer: pretty new to chef and I've inherited a bunch of chef cookbooks. The methods below are sub-optimal but it is what I have to work with for now. Be gentle, please. :) Also, please bear with me as I try to describe what I need.
Please note that we are using chef-client 11.16.4. Updating to 12.x, for now, is not an option.
tl;dr
Is there a way to specify a guard from the state of the current running block:
...
only_if { this_block_did_something }
notifies :run, 'bash[deploy-custom-docker-container]', :immediately
OK....
Take this chunk of code in a recipe I inherited and need to refactor a little...
# The identities of the innocent have been changed for their
# protection. Please ignore odd things in this example:
application app[:name] do
path app[:deploy_path]
enable_submodules true
repository app[:repository]
owner OWNER
group GROUP
symlinks({
"file.py" => "path/file.py"
})
revision app[:branch]
deploy_key data_bag_item('deployment_keys', 'keyname')['private_key']
end
link "/path/to/file.py" do
to "/path/to/settings-%s.py" % [file]
end
# This is where I need some direction...I think.
# note that CMD is a valid constant and the custom docker
# container does not follow any industry standard docker
# conventions due to our strange use-case. So I had to resort
# using a bash block to call our custom start/stop/restart script
bash 'deploy-custom-docker-container' do
code <<-EO
#{CMD} restart
EO
# currently a subscribes but I've tried other methods which
# don't achieve what I'm trying to accomplish
subscribes :run, 'application[%s]' % [app[:name]]
end
The application app[:name] deploys source code onto the target node whenever the repo has new code to be synced. The bash block restarts a very custom and non-industry standard docker container which uses the code.
In its current form, which is undesirable, the bash[deploy-custom-docker-container] block always gets executed irrespective of whether application app[:name] has to deploy code to a git repo or not (IE repo is up to date vs not up to date) on the target node. I'm sure I could create some code that determines if the repo was updated, touch a state/lock file, and then guard execution of the bash block by checking if that lockfile exists. To me, that would be a sub-optimal way to achieve my goal. What would be optimal is to use chef's state of the update as the method of setting the guard. Is that possible?? Read on...
In other words, when application app[:name] is hit during chef-client runtime, and a repo has been updated (and thus deployed on the node), chef-client reports the steps of application app[:name] deploying the new code. If the repo didn't need to be updated, chef-client happily skips the block with a "(up to date)" message. If the repo needed to be updated, chef-client shows the steps taken to deploy the code. So chef-client knows the state of the block of code it just ran.
Also, my observations of how chef-client runs in our environment has shown me that it doesn't matter if I put a notifies block in application app[:name] for bash[deploy-custom-docker-container] or use the subscribes method (pasted above); the bash block gets run irrespective of the state of the application app[:name]. I'd prefer that if the application app[:name] doesn't have an update to perform then the bash block doesn't run.
What I fear is that I will have to use a state file to determine the state of the update of the repo from the application app[:name] block. I'd rather just guard off the state of the run-time from chef's perspective of the application app[:name] block.
FIXED CODE
As pointed out by zts, my actions were wrong or missing. The following code is what I was able to come up with that resolved my issue.
application app[:name] do
...
notifies :run, 'link[%s]' % [filetolink], :immediately
end
link filetolink do
to file
notifies :run, 'bash[deploy-custom-docker-container]', :immediately
end
bash 'deploy-custom-docker-container' do
code <<-EO
#{CMD} restart
EO
action :nothing
end
This works for me now.
Notifications only fire if the notifying resource has changed (and the other way around, subscriptions only fire if the resource you're subscribing to has changed).
The reason the bash block runs irrespective of the notification is that, by default, bash blocks will run. If you only want a resource to run when notified, make sure to include action :nothing.
ie:
bash 'deploy-custom-docker-container' do
code <<-EO
#{CMD} restart
EO
action :nothing
subscribes :run, 'application[%s]' % [app[:name]]
end